0000439: Editing admin contact changes expiry date to a day early

(0001531)
ivan (administrator)
2009-08-15 09:43

I can reproduce this in trunk svn r5756

(0002516)
paulh (administrator)
2010-02-27 11:35

I've had another look at this, can't reproduce it was days in feb or march though if you set a contract to expire 30th June it sets it to 29th, if you then edit the admin contact it goes to the 28th and so on

Could be something to do with daylights savings?

(0002517)
ivan (administrator)
2010-02-27 11:56

Yeah pretty sure it's a daylight savings issue. There's an hour difference which is making it 23:00 the day before or something like that I think.

(0002519)
paulh (administrator)
2010-02-27 12:11

Yeap it is, its being passed in 2010-06-26, strtotime is converting this to 1277506800 which is

GMT: Fri, 25 Jun 2010 23:00:00 GMT
Your timezone: Sat 26 Jun 2010 00:00:00 BST

(0002732)
Tomse (developer)
2010-03-19 15:16
edited on: 2010-03-19 15:42

after having done some extensive testing with timezones and dst, I can confirm that the problem is DST.

date() has a I (capital i) flag that is DST aware.

using this we can modify the date/time before presenting it to the user.
the correct date is stored in MySQL, but it isn't compensated when returning the date to the user.

ericthefish mentioned modifying utc_time() to be dst aware.

after modifying this, we need to do some extensive testing.

holidays.php has been modified by adding 12 hours, as a workaround on this same kind of problem. but doing so will add a day if the user sets his/her profile to be UTC+14.

just as a reminder..
there probably should be a check whether the server is in the southern or northern hemisphere when calculating DST, since when we add one hour, the southern subtract one hour, ie time difference between Denmark and Brazil in the summer is 5 hours, but in the winter only 3 hours.

(0002735)
ivan (administrator)
2010-03-20 10:06

3.x svn r6280 adds a DST adjustment and 3.x svn r6282 allows this to be configured. I'm not sure whether this fixes things since my patch only adjusts for system time DST not user time DST. Needs some testing.

(0002736)
ivan (administrator)
2010-03-20 10:18

Reminder to self, change the display output back to date, rather than date time

(0002752)
ivan (administrator)
2010-03-20 16:15

3.x svn r6280 appears to have resolved this.

(0002847)
ivan (administrator)
2010-03-23 21:45

Fixed in git a7e584a

Issue History
Date Modified	Username	Field	Change
2009-01-26 15:00	paulh	New Issue
2009-08-15 09:43	ivan	Note Added: 0001531
2009-08-15 09:43	ivan	Status	new => confirmed
2009-08-15 09:43	ivan	Severity	minor => major
2010-02-25 21:25	paulh	Projection	none => minor fix
2010-02-25 21:25	paulh	ETA	none => < 1 day
2010-02-25 21:25	paulh	Target Version	=> 3.60 LTS
2010-02-27 11:35	paulh	Note Added: 0002516
2010-02-27 11:56	ivan	Note Added: 0002517
2010-02-27 12:11	paulh	Note Added: 0002519
2010-03-19 15:16	Tomse	Note Added: 0002732
2010-03-19 15:42	Tomse	Note Edited: 0002732	View Revisions
2010-03-20 10:06	ivan	Note Added: 0002735
2010-03-20 10:16	ivan	Status	confirmed => assigned
2010-03-20 10:16	ivan	Assigned To	=> ivan
2010-03-20 10:18	ivan	Note Added: 0002736
2010-03-20 16:15	ivan	Note Added: 0002752
2010-03-20 16:15	ivan	Status	assigned => resolved
2010-03-20 16:15	ivan	Fixed in Version	=> Current SVN
2010-03-20 16:15	ivan	Resolution	open => fixed
2010-03-20 17:43	ivan	Tag Attached: needsporting
2010-03-23 21:45	ivan	Note Added: 0002847
2010-03-23 21:45	ivan	Tag Detached: needsporting
2010-03-27 11:16	ivan	Fixed in Version	Current SVN => 3.60 LTS
2010-03-27 12:31	ivan	Status	resolved => closed

Notes
(0001531) ivan (administrator) 2009-08-15 09:43	I can reproduce this in trunk svn r5756

(0002516) paulh (administrator) 2010-02-27 11:35	I've had another look at this, can't reproduce it was days in feb or march though if you set a contract to expire 30th June it sets it to 29th, if you then edit the admin contact it goes to the 28th and so on Could be something to do with daylights savings?

(0002517) ivan (administrator) 2010-02-27 11:56	Yeah pretty sure it's a daylight savings issue. There's an hour difference which is making it 23:00 the day before or something like that I think.

(0002519) paulh (administrator) 2010-02-27 12:11	Yeap it is, its being passed in 2010-06-26, strtotime is converting this to 1277506800 which is GMT: Fri, 25 Jun 2010 23:00:00 GMT Your timezone: Sat 26 Jun 2010 00:00:00 BST

(0002732) Tomse (developer) 2010-03-19 15:16 edited on: 2010-03-19 15:42	after having done some extensive testing with timezones and dst, I can confirm that the problem is DST. date() has a I (capital i) flag that is DST aware. using this we can modify the date/time before presenting it to the user. the correct date is stored in MySQL, but it isn't compensated when returning the date to the user. ericthefish mentioned modifying utc_time() to be dst aware. after modifying this, we need to do some extensive testing. holidays.php has been modified by adding 12 hours, as a workaround on this same kind of problem. but doing so will add a day if the user sets his/her profile to be UTC+14. just as a reminder.. there probably should be a check whether the server is in the southern or northern hemisphere when calculating DST, since when we add one hour, the southern subtract one hour, ie time difference between Denmark and Brazil in the summer is 5 hours, but in the winter only 3 hours.

(0002735) ivan (administrator) 2010-03-20 10:06	3.x svn r6280 adds a DST adjustment and 3.x svn r6282 allows this to be configured. I'm not sure whether this fixes things since my patch only adjusts for system time DST not user time DST. Needs some testing.

(0002736) ivan (administrator) 2010-03-20 10:18	Reminder to self, change the display output back to date, rather than date time

(0002752) ivan (administrator) 2010-03-20 16:15	3.x svn r6280 appears to have resolved this.

(0002847) ivan (administrator) 2010-03-23 21:45	Fixed in git a7e584a

Relationships