Bug 12057 – REGRESSION: JavaScript Date Is One Day In The Future in GMT time zone

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Freddie Witherden]

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.

[David Kilzer (:ddkilzer)]

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.

[David Kilzer (:ddkilzer)]

(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.

[David Kilzer (:ddkilzer)]

Binary search of WebKit nightlies narrows down the regression between r16778 (which works) and r16797 (which exhibits the bug).

[David Kilzer (:ddkilzer)]

(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.

[David Kilzer (:ddkilzer)]

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.

[David Kilzer (:ddkilzer)]

(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".

[David Kilzer (:ddkilzer)]

Created attachment 12149 [details]
Patch v1

Proposed fix.

[David Kilzer (:ddkilzer)]

(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.

[David Kilzer (:ddkilzer)]

(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.

[Darin Adler]

Comment on attachment 12149 [details]
Patch v1

r=me

[David Kilzer (:ddkilzer)]

Committed revision 18514.

[David Kilzer (:ddkilzer)]

Mass removal of NeedsRadar keyword from my bugs that have already been RESOLVED.