Layout test failure: DST changes in US affect JavaScript date calculations

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Kirby White]

According to bug 11157 comment #5,

> According to the spec, history should not take into account what really
> happened but interpolate from a comparable year, where comparable years are
> judged by when Jan 1 happens and if the year is a leap year.
> This will only happen for dates that fall outside of the 1970-2038 range. if
> you fall out of that range then you are offset to a comparable year.
> This is consistent with what most browsers. [sic]

But DST switchover dates just changed in the US, which implies that the interpolated DST should also change for historical dates.  If we accept that, then in the fast/js/date-big-setdate.html layout test, April 5 1970 should no longer show a DST change, and the test is currently passing when it shouldn't.

I don't know if this has been discussed at the JS-spec level.  It remains to be seen what "most browsers" will do about it.

If the spec stays the same, then the test needs to be changed to use 8-9 Mar 1970 instead of 4-5 Apr, and getDSTOffset() in kjs/DateMath.cpp needs to be fixed to match.

[David Kilzer (:ddkilzer)]

Great catch, Kirby!  I think this illustrates how stupid JavaScript's (or is it ECMAScript's?) date rules are.  Why shouldn't JavaScript dates reflect reality?

Changing this bug to P1 and adding NeedsRadar keyword since I think this question needs to be answered before Safari is shipped:

Does the DST change shift for all dates in JavaScript now that it's changing in the U.S.?

Note that we need to change both the start and end dates for DST in the U.S.

[Mark Rowe (bdash)]

<rdar://problem/5045720>

[David Kilzer (:ddkilzer)]

(In reply to comment #1)
> Note that we need to change both the start and end dates for DST in the U.S.

Or do we even want to make this change since the spec specifies such a over-simplistic solution?

This issue appears to be tracked on this b.m.o. bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=365349

[David Kilzer (:ddkilzer)]

See ECMAScript-262, Section 15.9.1.9:

http://www.ecma-international.org/publications/standards/Ecma-262.htm

[David Kilzer (:ddkilzer)]

(In reply to comment #3)
> Or do we even want to make this change since the spec specifies such a
> over-simplistic solution?
> 
> This issue appears to be tracked on this b.m.o. bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=365349

Per this comment, Firefox uses the underlying OS for DST calculations (which technically violates the spec--not that this is a bad thing):

https://bugzilla.mozilla.org/show_bug.cgi?id=365349#c6

[David Kilzer (:ddkilzer)]

Brendan Eich weighed in on the ECMAScript spec here:

https://bugzilla.mozilla.org/show_bug.cgi?id=365349#c10
https://bugzilla.mozilla.org/show_bug.cgi?id=365349#c11

I guess I'm still not clear how how the DST algorithm should change, though.  Doesn't this mean that if you change DST to use the "current" algorithm that all dates before 2006 would change when DST went into effect?  I guess that's no different than using the pre-2007 algorithm before 1940-ish in the U.S., but it just seems wrong.

[Kirby White]

(In reply to comment #6)
> Brendan Eich weighed in on the ECMAScript spec here:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=365349#c10
> https://bugzilla.mozilla.org/show_bug.cgi?id=365349#c11

The problem I see is that the spec is now self-contradictory.  Determining "just whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time" and "map[ping] the year in question to an equivalent year for which the host environment provides daylight saving time information" don't match, for the current interpretation of an "equivalent" year.

It sounds to me like Brendan thinks current behavior is fine, which sounds good to me, but I'd feel better if the spec were clarified.  As it is, different implementations could give different results while still technically meeting the spec, which doesn't seem like a good thing.

[Kevin McCullough]

You are correct, different implementations can have different answers and still all be technically obeying the spec.  I don't believe this test is incorrect because by our algorithm it will interpolate to the year 1998 which is not changing it's DST.

Our algorithm interpolates dates outside of the 1970-2038 range to years within 1972-2028.  So perhaps we should write a test case that interpolates to this year or next which should have the new DST changes.  Also it's important to note that these changes only are reflected in the US, and I believe the some of the DST layout tests are known to fail in other timezones.

Finally I would suggest taking up Brendan Eich's suggestion (https://bugzilla.mozilla.org/show_bug.cgi?id=365349#c13) to help raise this issue.  I know OS X keeps a vast amount of historically accurate DST information from around the world, it would be great if we could just ask the OS and be done with it.

[Kevin McCullough]

After discussing with Geoff about the spec a little more, I'm reopening this as a valid issue.  I misunderstood the issue, the test that we have currently should be behaving as if this year's new DST change affected it.  As I stated before it mapped to 1998 but should map to a year that is in the present or future with the current DST rules, not a year in the past.

Also I want to change the test, it should involve at least 3 dates (past present future) that are all equivalent with respect to DST and the spec, and verify that they all observe DST at the same time.

[Darin Adler]

(In reply to comment #1)
> Great catch, Kirby!  I think this illustrates how stupid JavaScript's (or is it
> ECMAScript's?) date rules are.  Why shouldn't JavaScript dates reflect reality?

As an aside (probably not entirely relevant to fixing this bug):

I suspect that ECMAScript's rules for dates are simply a standards-ese way of saying "match the Windows OS system calls", because I believe Windows implementation of calls like these does not take historical DST into account.

Supporting that theory is the fact that Firefox more or less matches the spec on Windows but does yield historical DST results on Macintosh.

[David Kilzer (:ddkilzer)]

(In reply to comment #10)
> (In reply to comment #1)
> > Great catch, Kirby!  I think this illustrates how stupid JavaScript's (or is it
> > ECMAScript's?) date rules are.  Why shouldn't JavaScript dates reflect reality?

That was a poor choice of words--I apologize.  I'm sure it's not easy writing a spec that everyone must agree to (and adhere to), especially with so much historical data in place.  It's a no-win situation.

> I suspect that ECMAScript's rules for dates are simply a standards-ese way of
> saying "match the Windows OS system calls", because I believe Windows
> implementation of calls like these does not take historical DST into account.
> 
> Supporting that theory is the fact that Firefox more or less matches the spec
> on Windows but does yield historical DST results on Macintosh.

However, it would be nice if the spec was clearer on whether the JavaScript implementation could reflect the DST date/time behavior of the underlying operating system which Firefox does now.  Of course, that would break down as soon as someone writes an entire operating system in JavaScript, or implements a JavaScript-interpreter-on-a-chip!

(In reply to comment #11)
> However, it would be nice if the spec was clearer on whether the JavaScript
> implementation could reflect the DST date/time behavior of the underlying
> operating system which Firefox does now.

I think it's clear enough that such behavior violates the spec. Having said that, I would like WebKit to violate the spec in that manner. I don't know of any real-world example where following the spec is beneficial.

[David Kilzer (:ddkilzer)]

Two JavaScriptCore tests are now failing after the early DST switch:

    ecma/Date/15.9.5.14.js
    ecma/Date/15.9.5.34-1.js

in addition to the original reason for this bug:  a false-positive for LayoutTests/fast/js/date-big-setdate.html.

[Kevin McCullough]

Sorry for the delay, I was hoping to have this in before the DST change.  I know of a nother error which I have filed a radar about but not a bugzilla yet, and I need to ensure my change doesn't cause a performance regression.

[Kevin McCullough]

fixed in r20203