58118 - ECMA Compliance: daylight savings time wrong prior to year 1

Status: RESOLVED FIXED

(Rhino Graveyard :: Core, defect, P3)

Description

[David Flanagan]

Rhino computes daylight savings time wrong for years before 1AD
It appears to never recognize daylight savings time before year 1.

oxymoron:44 % java -jar js.jar
js> d = new Date(2000,6)
Sat Jul 01 00:00:00 GMT-0700 (PDT) 2000
js> d.setFullYear(1900)                  
-2193325200000
js> d
Sun Jul 01 00:00:00 GMT-0700 (PDT) 1900
js> d.setFullYear(0)
-62151465600000
js> d
Sat Jul 01 00:00:00 GMT-0800 (PST) 0000
js> d.setFullYear(-1000)
-93708460800000
js> d
Tue Jul 01 00:00:00 GMT-0800 (PST) -1000
js> d.getTimezoneOffset()
480
js> d.setFullYear(2000)
962434800000
js> d
Sat Jul 01 00:00:00 GMT-0700 (PDT) 2000
js> d.getTimezoneOffset()
420

See section 15.9.1.8 of the ECMA v3 spec, which says that the daylight
savings time adjustment should be applied to all dates, regardless of year.
That is, there should be no attempt to track the actual historical definitions
and adoption of daylight savings time.

See also bug #58116: spidermonkey has a similar bug for years before 1970

Comment 1

[Phil Schwartau]

Here is the ECMA section:


15.9.1.8 Daylight Saving Time Adjustment

An implementation of ECMAScript is expected to determine the daylight saving time 
algorithm. The algorithm to determine the daylight saving time adjustment 
DaylightSavingTA(t), measured in milliseconds, must depend only on four things:

(1) the time since the beginning of the year    
          t – TimeFromYear(YearFromTime(t))
(2) whether t is in a leap year                 
          InLeapYear(t)
(3) the week day of the beginning of the year
          WeekDay(TimeFromYear(YearFromTime(t))
and
(4) the geographic location.

The implementation of ECMAScript should not try to determine whether the exact 
time was subject to daylight saving time, but just whether daylight saving time 
would have been in effect if the current daylight saving time algorithm had been 
used at the time. This avoids complications such as taking into account the years 
that the locale observed daylight saving time year round.

If the host environment provides functionality for determining daylight saving 
time, the implementation of ECMAScript is free to map the year in question to 
an equivalent year (same leap-year-ness and same starting week day for the year) 
for which the host environment provides daylight saving time information. The 
only restriction is that all equivalent years should produce the same result.

Comment 2

[Norris Boyd]

Mike, do you want this one, too?

Comment 3

[Mike McCabe]

Sure!  I just got the Spider Monkey counterpart.

Comment 4

[Mike McCabe]

Attachment: proposed fix; new EquivalentYear function.

Comment 5

[Mike McCabe]

A little discussion of EquivalentYear is in 58116.

With the same EquivalentYear fix in Spider Monkey, Rhino's (java's) current
notion of daylight savings begins differing from that of Spider Monkey in 1581! 
(before, of course, giving up the ghost at year 0.)  Since there pretty likely
wasn't daylight savings in 1581, I think this patch probably gives more-correct
behavior.

They match out to year 4000, so I think I got the mod 400 leap year behavior
right.

Comment 6

[Mike McCabe]

Attachment: updated version of last patch, also gets equiv. year before formatting timezone.

Comment 7

[Mike McCabe]

CCing Norris.

Comment 8

[Phil Schwartau]

Reassigning Mike's Rhino bugs to Patrick, as per recent meeting - 

Comment 9

[Igor Bukanov]

I look at the patch

Comment 10

[Igor Bukanov]

Attachment: Patch update to reflect code evolution during past 3 years

Comment 11

[Igor Bukanov]

Attachment: Patch update to include only essential changes

Comment 12

[Igor Bukanov]

I committed the patch