Bug 9532 - date setUTCFullYear to setUTCMinutes adding 1 hour in time zone 0
Summary: date setUTCFullYear to setUTCMinutes adding 1 hour in time zone 0
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 417.x
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-21 09:25 PDT by toby lewis
Modified: 2007-12-30 10:20 PST (History)
5 users (show)

See Also:


Attachments
test case (1.15 KB, text/html)
2006-06-21 14:35 PDT, Alexey Proskuryakov
no flags Details
First attempt (1.02 KB, patch)
2006-06-23 13:26 PDT, Rob Buis
darin: review-
Details | Formatted Diff | Diff
Improved patch (1.10 KB, patch)
2006-06-27 05:49 PDT, Rob Buis
darin: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description toby lewis 2006-06-21 09:25:52 PDT
This bug only occurs when the timezone in date & time is set to Europe/London or any of the others in the 0 zone.  It does not occur in any of the US time zones.

Setting parts of a date with the local methods (eg setDate()) is fine, but if any of the UTC methods (eg setUTCDate()) are used one extra hour is added to the date value.  

This is occuring on all dates and not just ones around the clock change dates.

It happens regardless of whether the change is increasing or decreasing the date.

It occurs when daylight saving is applicable to the date being edited and when daylight saving is not.  

Likewise it happens both when the system clock is set to the summer or the winter.  

Basically it always happens.

the following code demonstrates the problem when the system timezone is set to Europe/London.  Before and after values are shown using UTC and local methods and the test is done by setting with a UTC and a local method to show the difference in the result.  I have checked this behavior against both MSIE (spit) and Firefox and they both behave as expected (ie differently to Safari).


var test1 = new Date(Date.UTC(2006, 1, 20));
var result = 'changing date with setUTCDate';
result += 'initial UTC: '+test1.getUTCMonth()+'/'+test1.getUTCDate()+' - '+test1.getUTCHours()+':'+test1.getUTCMinutes();
result += ' local: '+test1.getMonth()+'/'+test1.getDate()+' - '+test1.getHours()+':'+test1.getMinutes()+'\n';
test1.setUTCDate(15);
result += 'after UTC: '+test1.getUTCMonth()+'/'+test1.getUTCDate()+' - '+test1.getUTCHours()+':'+test1.getUTCMinutes();
result += ' local: '+test1.getMonth()+'/'+test1.getDate()+' - '+test1.getHours()+':'+test1.getMinutes()+'\n';

result += 'changing date with setDate';
var test1 = new Date(Date.UTC(2006, 1, 20));
result += 'initial UTC: '+test1.getUTCMonth()+'/'+test1.getUTCDate()+' - '+test1.getUTCHours()+':'+test1.getUTCMinutes();
result += ' local: '+test1.getMonth()+'/'+test1.getDate()+' - '+test1.getHours()+':'+test1.getMinutes()+'\n';
test1.setDate(15);
result += 'after UTC: '+test1.getUTCMonth()+'/'+test1.getUTCDate()+' - '+test1.getUTCHours()+':'+test1.getUTCMinutes();
result += ' local: '+test1.getMonth()+'/'+test1.getDate()+' - '+test1.getHours()+':'+test1.getMinutes()+'\n';
alert(result);
Comment 1 Alexey Proskuryakov 2006-06-21 14:35:25 PDT
Created attachment 8955 [details]
test case

Same test, as an attachment.
Comment 2 Alexey Proskuryakov 2006-06-21 14:46:10 PDT
Confirmed. TOT behavior seems to be even more broken, needs investigation.
Comment 3 Rob Buis 2006-06-23 13:26:35 PDT
Created attachment 8988 [details]
First attempt

To me it seems related to BST handling in 1970(which is default for t3):

http://en.wikipedia.org/wiki/British_Summer_Time

Now this is not a problem in itself, but the tm structure seems to indicate summer time, even
at 1-1-1970! I guess that is correct given the wikipedia page, but it is not helping our calculation.
One way I found to fix it is to just use the current time, assuming that from now on we stick to winter
and summertime as we know it since years. I am welcome to input on how to test and suggestions
for better, or likely more efficient fixes. One way could be to single out the BST case?
Cheers,

Rob.
Comment 4 Darin Adler 2006-06-23 21:37:17 PDT
Comment on attachment 8988 [details]
First attempt

I don't like the fact that the call to localtime_r is now dependent on the current time. Perhaps that's a clever elegant solution, but I'm worried that makes this function "less deterministic". And the local variable clearly should not be named zero if it's going to be used this way.

We really want the utcOffset at time t, not the utcOffset at the current time.

I'm not absolutely certain of this, but I think I'm certain enough to say review-.

Feel free to research further and put this up for review again if I'm wrong.
Comment 5 toby lewis 2006-06-23 23:29:53 PDT
I don't know anything about the source code, but just from a logical point of view, UTC is UTC and should have nothing to do with time zones or daylight savings.  The setUTC functions should be far simpler than the locale set functions.  The way I have worked around the problem in javascript was simply to do the millisecond calculations myself and use mydate.setTime() which only needed about twenty lines of code.
Comment 6 Rob Buis 2006-06-27 05:49:33 PDT
Created attachment 9058 [details]
Improved patch

This patch seems to work better, it uses the utcOffset info of the new date, instead of 1/1/1970.
It may need more testing though.
Cheers,

Rob.
Comment 7 Darin Adler 2006-06-27 09:27:14 PDT
Comment on attachment 9058 [details]
Improved patch

Makes no sense for this variable to be named "zero" any more if it's not zero. So you should fix that. I also don't understand quite how this fixes the bug. A comment explaining that would be welcome.
Comment 8 David Kilzer (:ddkilzer) 2007-12-30 00:37:52 PST
This may be related to Bug 12057 and r18514.
http://trac.webkit.org/projects/webkit/changeset/18514

Comment 9 David Kilzer (:ddkilzer) 2007-12-30 00:39:30 PST
(In reply to comment #8)
> This may be related to Bug 12057 and r18514.
> http://trac.webkit.org/projects/webkit/changeset/18514

It may already be fixed as well.

Comment 10 David Kilzer (:ddkilzer) 2007-12-30 00:42:10 PST
(In reply to comment #9)
> It may already be fixed as well.

Then again, I doubt this is fixed, although the fix would be to use Jan 1, 2000 as the basis for UTC timezone offset instead of Jan 1, 1970 for the same reasons as bug 12057 used that date.

Comment 11 David Kilzer (:ddkilzer) 2007-12-30 10:20:14 PST
(In reply to comment #10)
> (In reply to comment #9)
> > It may already be fixed as well.
> 
> Then again, I doubt this is fixed, although the fix would be to use Jan 1, 2000
> as the basis for UTC timezone offset instead of Jan 1, 1970 for the same
> reasons as bug 12057 used that date.

No, it's fixed.  :)  The original failure was probably fixed by r16780, and then the UTC time zone issue was fixed by r18514.

http://trac.webkit.org/projects/webkit/changeset/16780