Bug 80262

Summary: REGRESSION (r76714): Date.toLocaleString not taking time zone into account
Product: WebKit Reporter: Andy Wingo <wingo>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: ap, barraclough, darin, efidler, oliver, pnormand, tonikitoo
Priority: P1 Keywords: Regression
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Description Andy Wingo 2012-03-05 04:04:36 PST
Bug 76714 introduced a regression in Date.toLocaleDateString().

Before:

> var TIME_1900 = -2208988800000;
undefined
> new Date(TIME_1900)
Mon Jan 01 1900 01:00:00 GMT+0100 (CET)
> new Date(TIME_1900).toLocaleDateString()
01/01/1900

After:

> var TIME_1900 = -2208988800000;
undefined
> new Date(TIME_1900)
Mon Jan 01 1900 01:00:00 GMT+0100 (CET)
> new Date(TIME_1900).toLocaleDateString()
December 31, 1899

This causes ecma_3/Date/15.9.5.6.js to fail.
Comment 1 Andy Wingo 2012-03-05 05:44:57 PST
It's worse than I thought at first:

> var TIME_1900 = -2208988800000;
undefined
> new Date(TIME_1900).toTimeString()
01:00:00 GMT+0100 (CET)
> new Date(TIME_1900).toLocaleTimeString()
11:45:16 PM GMT-00:14:44

I think we should probably just revert the patch entirely.  I tried to add Eli Findler onto the Cc, but bugzilla isn't having it.

Darin, WDYT?
Comment 2 Andy Wingo 2012-03-05 08:46:06 PST
Note that the Mac port is not affected by this regression, I don't think.
Comment 3 Eli Fidler 2012-03-05 16:20:34 PST
That's odd... on QNX:

> var TIME_1900 = -2208988800000;
undefined
> new Date(TIME_1900)
Mon Jan 01 1900 01:00:00 GMT+0100 (CET)
> new Date(TIME_1900).toLocaleDateString()
"January 1, 1900"
> new Date(TIME_1900).toLocaleString()
"January 1, 1900 1:00:00 AM GMT+01:00"
> new Date(TIME_1900).toTimeString()
"01:00:00 GMT+0100 (CET)"
> new Date(TIME_1900).toLocaleTimeString()
"1:00:00 AM GMT+01:00"

What platform are you seeing the regression on?
Comment 4 Andy Wingo 2012-03-06 00:50:56 PST
(In reply to comment #3)
> That's odd... on QNX:
> 
> > var TIME_1900 = -2208988800000;
> undefined
> > new Date(TIME_1900)
> Mon Jan 01 1900 01:00:00 GMT+0100 (CET)
> > new Date(TIME_1900).toLocaleDateString()
> "January 1, 1900"
> > new Date(TIME_1900).toLocaleString()
> "January 1, 1900 1:00:00 AM GMT+01:00"
> > new Date(TIME_1900).toTimeString()
> "01:00:00 GMT+0100 (CET)"
> > new Date(TIME_1900).toLocaleTimeString()
> "1:00:00 AM GMT+01:00"
> 
> What platform are you seeing the regression on?

Strange that it's working for you and not for me.  I use the WebKitGTK+ port, and my GNU/Linux system has ICU 4.8.1.1-3 installed.

Are you in the CET time zone?  We could look into this over IRC if you like.
Comment 5 Philippe Normand 2012-03-06 08:57:16 PST
I think the issue doesn't show up on the bots because they're configured to be in  west coast time with TZ=PST8PDT.
Comment 6 Eli Fidler 2012-03-06 16:01:27 PST
weird.. I can reproduce this bug with TZ="Europe/Madrid" or TZ="Europe/Paris" or TZ="Europe/Amsterdam", but not TZ="CET" or TZ="Europe/Copenhagen" or TZ="America/Toronto".

Sounds like maybe an ICU issue. I'll keep looking.
Comment 7 Eli Fidler 2012-03-06 17:30:07 PST
Looks like this behaviour is correct. According to the Olson timezone database, Copenhagen switched from their odd GMT offset before 1900, but Paris, Amsterdam and Madrid did so after 1900. CET has a constant offset to GMT. 

I assume Andy is in "Europe/Madrid" timezone, which is defined as:
Zone	Europe/Madrid	-0:14:44 -	LMT	1901 Jan  1  0:00s
			 0:00	Spain	WE%sT	1946 Sep 30
			 1:00	Spain	CE%sT	1979
			 1:00	EU	CE%sT
Comment 8 Gavin Barraclough 2012-03-06 18:54:00 PST
Looks like I'm seeing this bug too.
Comment 9 Gavin Barraclough 2012-03-06 18:57:20 PST
Hmmm, I'm on a mac, so it doesn't look like what I'm seeing will be a regression due to bug#76714, but but it has the same symptom that Andy is reporting.

I'll investigate & re-title if appropriate.
Comment 10 Gavin Barraclough 2012-03-07 19:46:36 PST
Ugh, my bad, missed the -0:14:44 in Eli's comment.  Had considered historic timezones, but had incorrectly assumed an odd shift like that was more likely a math bug!

> > var TIME_1900 = -2208988800000;
> undefined
> > new Date(TIME_1900).toTimeString()
> 01:00:00 GMT+0100 (CET)
> > new Date(TIME_1900).toLocaleTimeString()
> 11:45:16 PM GMT-00:14:44

Per the spec, toLocaleTimeString is implementation defined, so 'correct' is ambiguous, but per common sense this is actually a progression.  At midnight UTC, 1st Jan 1900, in Madrid it was 11:45:16pm, of Dec 31 1899.  The spec defined time conversions are restricted from using historic information, but the locale methods are not, and are free to actually be correct. :-)
Comment 11 Andy Wingo 2012-03-08 06:54:33 PST
Thanks for tracking this one down.  I'll add an exception for this test to run-javascriptcore-tests, if that's OK.