Bug 80262 – REGRESSION (r76714): Date.toLocaleString not taking time zone into account

• Status: RESOLVED
• Resolution: INVALID
• Component: JavaScriptCore

[Andy Wingo]

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.

[Andy Wingo]

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?

[Andy Wingo]

Note that the Mac port is not affected by this regression, I don't think.

[Eli Fidler]

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?

[Andy Wingo]

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

[Philippe Normand]

I think the issue doesn't show up on the bots because they're configured to be in  west coast time with TZ=PST8PDT.

[Eli Fidler]

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.

[Eli Fidler]

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

[Gavin Barraclough]

Looks like I'm seeing this bug too.

[Gavin Barraclough]

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.

[Gavin Barraclough]

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. :-)

[Andy Wingo]

Thanks for tracking this one down.  I'll add an exception for this test to run-javascriptcore-tests, if that's OK.