Bug 82435 – REGRESSION(r105939): Date.toLocaleString()'s ICU implementation is incorrect between 00:00-01:00 (PDT) if the timezone is Los Angeles

• Component: Tools / Tests
• Status: NEW

[Csaba Osztrogonác]

It fails only on the Qt5 bot. So it might be a regression in Qt5.

[Csaba Osztrogonác]

It started to fail near Mar 09 - 12.

[Csaba Osztrogonác]

The problem is with this test case:
(Date.parse(now.toLocaleDateString()) - (midnight(now)).valueOf()) == 0 = false FAILED! expected: true

You can easily reproduce it with Qt5 based JSC:
new Date("Fri Jun 22 2012 00:56:27 GMT-0700 (PDT)").toLocaleDateString()
June 21, 2012

new Date("Fri Jun 22 2012 01:00:00 GMT-0700 (PDT)").toLocaleDateString()
June 22, 2012

Otherwise it isn't a good idea to use new Date() as now in a test case.
It makes test cases undeterministic ...

[Csaba Osztrogonác]

I got it, the bug is related to daylight saving:

> new Date("Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)").toLocaleDateString()
March 11, 2012
> new Date("Sun Mar 11 2012 00:59:59 GMT-0800 (PST)").toLocaleDateString()
March 11, 2012

[Csaba Osztrogonác]

It isn't Qt specific bug, it is a general bug. 

http://trac.webkit.org/changeset/105939/trunk/Source/JavaScriptCore/runtime/DatePrototype.cpp made Date.toLocaleString() using ICU. This new ICU case doesn't work in PDT, but works in PST. The non-ICU case works fine in PDT and PST too, so it is a regression related to daylight saving.

[Csaba Osztrogonác]

I found a similar discussion about this bug - https://bugs.webkit.org/show_bug.cgi?id=80262

ECMA spec says:
"15.9.5.6  Date.prototype.toLocaleDateString() 
This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the "date" portion
of the Date in the current time zone in a convenient, human-readable form
that corresponds to the conventions of the host environment‘s current locale."

So toLocaleDateString() "are intended to represent the "date" portion
of the Date in the current time zone", so "June 21, 2012" can't be correct
if the time is new Date("Fri Jun 22 2012 00:56:27 GMT-0700 (PDT)") or 
new Date("Fri Jun 22 2012 00:56:27") and we are in PDT.

[Eli Fidler]

I can't reproduce this failure. On my Ubuntu machine with Qt5 WebKit:

$ cat date.js 
print(new Date("Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)").toString())
print(new Date("Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)").toLocaleString())
print(new Date("Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)").toLocaleDateString())
print(new Date("Mon Mar 11 2012 00:59:59 GMT-0800 (PST)").toLocaleDateString())

$ TZ=PST8PDT ./jsc date.js 
Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)
12 March, 2012 12:59:59 AM PDT
12 March, 2012
11 March, 2012

$ TZ=PST8 ./jsc date.js 
Sun Mar 11 2012 23:59:59 GMT-0800 (PST)
11 March, 2012 11:59:59 PM GMT-08:00
11 March, 2012
11 March, 2012

Maybe your timezone database is weird?

I wonder if the testcase is valid, since nothing specifies that it's valid to construct a Date from the output of Date.toLocale*String().

[Csaba Osztrogonác]

I tried your date.js on my Debian Squeeze and Ubuntu 11.10
and got the following results:

export TZ=/usr/share/zoneinfo/America/Los_Angeles
$ WebKitBuild/Release/bin/jsc date.js
Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)
March 11, 2012 11:59:59 PM GMT-08:00
March 11, 2012
March 11, 2012
------------------------------------------------------ 
export TZ=PST8PDT
$ WebKitBuild/Release/bin/jsc date.js
Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)
March 12, 2012 12:59:59 AM PDT
March 12, 2012
March 11, 2012


It seems the bug is invalid in PST8PDT timezone, but still valid in Los_Angeles
timezone. It is strange for me, because PST8PDT should be same as Los_Angeles now.

Have you got any idea what the problem is?

[Csaba Osztrogonác]

I don't have any idea what is the problem with Los Angeles timezone,
and I have no idea how to fix it ... But I'm going to change our timezone
to PST8PDT to paint our buildbots green (hide this annoying bug).

[Eli Fidler]

(In reply to comment #7)
> I tried your date.js on my Debian Squeeze and Ubuntu 11.10
> and got the following results:
> 
> export TZ=/usr/share/zoneinfo/America/Los_Angeles
> $ WebKitBuild/Release/bin/jsc date.js
> Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)
> March 11, 2012 11:59:59 PM GMT-08:00
> March 11, 2012
> March 11, 2012
> ------------------------------------------------------ 
> export TZ=PST8PDT
> $ WebKitBuild/Release/bin/jsc date.js
> Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)
> March 12, 2012 12:59:59 AM PDT
> March 12, 2012
> March 11, 2012
> 
> 
> It seems the bug is invalid in PST8PDT timezone, but still valid in Los_Angeles
> timezone. It is strange for me, because PST8PDT should be same as Los_Angeles now.
> 
> Have you got any idea what the problem is?

I don't think you can specify a path in the TZ environment variable:

$ TZ=PST8 ./jsc ~/date.js 
Sun Mar 11 2012 23:59:59 GMT-0800 (PST)
11 March, 2012 11:59:59 PM GMT-08:00
11 March, 2012
11 March, 2012
$ TZ=PST8PDT ./jsc ~/date.js 
Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)
12 March, 2012 12:59:59 AM PDT
12 March, 2012
11 March, 2012
$ TZ=America/Los_Angeles ./jsc ~/date.js 
Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)
12 March, 2012 12:59:59 AM PDT
12 March, 2012
11 March, 2012
$ TZ=/usr/share/zoneinfo/America/Los_Angeles ./jsc ~/date.js 
Mon Mar 12 2012 00:59:59 GMT-0700 (PDT)
11 March, 2012 11:59:59 PM GMT-08:00
11 March, 2012
11 March, 2012

[Csaba Osztrogonác]

I tried TZ=America/Los_Angeles and it works for me, but I 
have no idea why TZ=/usr/share/zoneinfo/America/Los_Angeles
doesn't work ... It worked for us for years ... 

After this change started this test fail ... Maybe 
ICU can't understand TZ if we give the full path?