It fails only on the Qt5 bot. So it might be a regression in Qt5.
It started to fail near Mar 09 - 12.
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 ...
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
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.
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.
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().
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 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).
(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
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?