Bug 82435 - REGRESSION(r105939): Date.toLocaleString()'s ICU implementation is incorrect between 00:00-01:00 (PDT) if the timezone is Los Angeles
Summary: REGRESSION(r105939): Date.toLocaleString()'s ICU implementation is incorrect ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Critical
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2012-03-28 00:43 PDT by Csaba Osztrogonác
Modified: 2012-09-13 04:08 PDT (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Csaba Osztrogonác 2012-03-28 00:43:18 PDT
It fails only on the Qt5 bot. So it might be a regression in Qt5.
Comment 1 Csaba Osztrogonác 2012-03-28 00:51:20 PDT
It started to fail near Mar 09 - 12.
Comment 2 Csaba Osztrogonác 2012-06-22 02:27:32 PDT
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 ...
Comment 3 Csaba Osztrogonác 2012-06-22 03:17:43 PDT
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
Comment 4 Csaba Osztrogonác 2012-06-22 04:19:05 PDT
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.
Comment 5 Csaba Osztrogonác 2012-06-22 04:36:03 PDT
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.
Comment 6 Eli Fidler 2012-06-23 10:00:57 PDT
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().
Comment 7 Csaba Osztrogonác 2012-09-11 02:36:40 PDT
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?
Comment 8 Csaba Osztrogonác 2012-09-11 02:38:19 PDT
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).
Comment 9 Eli Fidler 2012-09-11 09:57:16 PDT
(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
Comment 10 Csaba Osztrogonác 2012-09-13 04:08:23 PDT
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?