Bug 12057 - REGRESSION: JavaScript Date Is One Day In The Future in GMT time zone
Summary: REGRESSION: JavaScript Date Is One Day In The Future in GMT time zone
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: David Kilzer (:ddkilzer)
URL: javascript:alert(new Date())
Keywords: HasReduction, Regression
Depends on:
Blocks:
 
Reported: 2007-01-01 08:00 PST by Freddie Witherden
Modified: 2007-06-24 12:04 PDT (History)
3 users (show)

See Also:


Attachments
Patch v1 (2.67 KB, patch)
2007-01-01 15:45 PST, David Kilzer (:ddkilzer)
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Freddie Witherden 2007-01-01 08:00:29 PST
The value returned by new Date(), for some reason is one day in the future in the latest webkit build, however it is fine in the latest version of Safari.

In WebKit:
Tue Jan 02 2007 15:51:05 GMT+2400 (BST)
In Safari:
Mon Jan 01 2007 15:51:31 GMT
In Mozilla:
Mon Jan 01 2007 15:52:35 GMT+0000 (BST)

My time is BST and the date on my macs clock is correct.
Comment 1 David Kilzer (:ddkilzer) 2007-01-01 08:14:14 PST
Confirmed with WebKit nightly r18481.  (Set your timezone to BST by changing the nearest city to London in the Date & Time pane of the System Preferences.)

However, using a locally-built debug build of WebKit r18502 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8N1037), I can't reproduce this bug.

Comment 2 David Kilzer (:ddkilzer) 2007-01-01 08:16:08 PST
(In reply to comment #1)
> Confirmed with WebKit nightly r18481.  (Set your timezone to BST by changing
> the nearest city to London in the Date & Time pane of the System Preferences.)
> 
> However, using a locally-built debug build of WebKit r18502 with Safari 2.0.4
> (419.3) on Mac OS X 10.4.8 (8N1037), I can't reproduce this bug.

After restarting WebKit while my MacBook Pro was already in the BST timezone, I now see the same behavior on the locally-built r18502.

Comment 3 David Kilzer (:ddkilzer) 2007-01-01 09:16:29 PST
Binary search of WebKit nightlies narrows down the regression between r16778 (which works) and r16797 (which exhibits the bug).

Comment 4 David Kilzer (:ddkilzer) 2007-01-01 09:22:20 PST
(In reply to comment #3)
> Binary search of WebKit nightlies narrows down the regression between r16778
> (which works) and r16797 (which exhibits the bug).

If I had to guess, it was probably r16780 that caused the regression, although other interesting changes include r16783, r16786, r16793 and r16795.

Comment 5 David Kilzer (:ddkilzer) 2007-01-01 13:06:15 PST
After tracing through KJS::getUTCOffset() with the timezone set to GMT (London - England) on Mac OS X 10.4.8 (8N1037), I've found that Jan 02, 1970 (which is the date used to calculate UTC and DST offsets) resolves to BST (British Summer Time; +0100) instead of GMT (+0000).

I can only assume that BST was in effect on Jan 02, 1970, or that there is a bug in Mac OS X.

Comment 6 David Kilzer (:ddkilzer) 2007-01-01 13:15:10 PST
(In reply to comment #5)
> I can only assume that BST was in effect on Jan 02, 1970, or that there is a
> bug in Mac OS X.

According to these two links, "BST" was "British Standard Time" (+0100) during 1968-1971 and was a year-round time zone:

http://en.wikipedia.org/wiki/British_Summer_Time
http://www.srcf.ucam.org/~jsm28/british-time/

It appears that getUTCOffset() needs a fix similar to getDSTOffset(double) since Mac OS X has, "historically accurate [time zone] information".

Comment 7 David Kilzer (:ddkilzer) 2007-01-01 15:45:18 PST
Created attachment 12149 [details]
Patch v1

Proposed fix.
Comment 8 David Kilzer (:ddkilzer) 2007-01-01 15:46:01 PST
(In reply to comment #7)
> Created an attachment (id=12149) [edit]
> Patch v1
> 
> Proposed fix.

All layout tests and javascriptcore tests pass with this change.
Comment 9 David Kilzer (:ddkilzer) 2007-01-01 15:47:50 PST
(In reply to comment #7)
> Created an attachment (id=12149) [edit]
> Patch v1
> 
> Proposed fix.

Note that we could have called mktime(&localt), then checked the value of localt.tm_gmtoff instead, but Windows doesn't support this value in its struct tm data structure.

Comment 10 Darin Adler 2007-01-01 19:50:58 PST
Comment on attachment 12149 [details]
Patch v1

r=me
Comment 11 David Kilzer (:ddkilzer) 2007-01-01 20:35:20 PST
Committed revision 18514.

Comment 12 David Kilzer (:ddkilzer) 2007-06-24 12:04:45 PDT
Mass removal of NeedsRadar keyword from my bugs that have already been RESOLVED.