1093130 - [js] new Date(1970, 0, 1).getFullYear() returns 1969

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Wilson Page [:wilsonpage]]

Firefox: new Date(1970, 0, 1).getFullYear(); //=> 1969
Chrome: new Date(1970, 0, 1).getFullYear(); //=> 1970

I'm based in London, UK timezone.

http://stackoverflow.com/questions/26717400/why-does-new-date1970-0-1-getfullyear-return-1969#26717480

Comment 1

[Wilson Page [:wilsonpage]]

Also Firefox: new Date(1965, 0, 1).getFullYear(); //=> 1964

Comment 2

[André Bargull [:anba]]

Bug 830304 contains a WIP patch for this issue.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Wilson, what does "+new Date(1970, 0, 1)" return for you in Firefox and Chrome?  Are they both 18000000?

Comment 4

[Wilson Page [:wilsonpage]]

(In reply to Boris Zbarsky [:bz] from comment #3)
> Wilson, what does "+new Date(1970, 0, 1)" return for you in Firefox and
> Chrome?  Are they both 18000000?

Firefox: -3600000
Chrome: 0

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.  So the issue seems to be happening there already.  That constructor does involve conversion from local time to UTC....

Did you really mean -3600000 and not -36000000 (-36e5 vs -36e6)?

What do Firefox and Chrome return for the following expressions for you:

  (new Date(-36000000)).toString()
  (new Date(0)).toString()  
  (new Date(-36000000)).toUTCString()
  (new Date(0)).toUTCString()

Comment 6

[Boris Zbarsky [:bzbarsky]]

Er, I guess you did mean -3600000; that's -1 hour.

In that case, could you please use that value, not -36e6) in the tests I asked for in comment 5?

Comment 7

[Jon Coppeard (:jonco)]

(In reply to Boris Zbarsky [:bz] from comment #5)
> That constructor does involve conversion from local time to UTC....

Due to the British Standard Time experiment, the UK was on GMT+1 between 27 October 1968 and 31 October 1971, so maybe this is correct?

http://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation

The same thing for 1965 is not correct, but I think that's because of the way we handle dates before 1970 by mapping them to 'equivalent' years to calculate DST.  In this case we map 1965 to 1971 because it starts on a Friday, and 1971 falls inside this period.

Comment 8

[Wilson Page [:wilsonpage]]

FIREFOX

(new Date(-3600000)).toString(); => "Wed Dec 31 1969 23:00:00 GMT+0000 (BST)"
(new Date(0)).toString(); => "Thu Jan 01 1970 01:00:00 GMT+0100 (BST)"
(new Date(-3600000)).toUTCString(); => "Wed, 31 Dec 1969 23:00:00 GMT"
(new Date(0)).toUTCString(); => "Thu, 01 Jan 1970 00:00:00 GMT"

CHROME

(new Date(-3600000)).toString(); => "Wed Dec 31 1969 23:00:00 GMT+0000 (GMT)"
(new Date(0)).toString(); => "Thu Jan 01 1970 00:00:00 GMT+0000 (BST)"
(new Date(-3600000)).toUTCString(); => "Wed, 31 Dec 1969 23:00:00 GMT"
(new Date(0)).toUTCString(); => "Thu, 01 Jan 1970 00:00:00 GMT"

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK.  The Date(0) case is clearly mishandled in Chrome per comment 7: it should be GMT+1 but they list it as GMT+0.  That leads to the other observed results here, though we should perhaps file a bug on the 1965 thing, because mapping to equivalent years to compute DST makes no sense.

Comment 10

[Boris Zbarsky [:bzbarsky]]

I filed https://bugs.webkit.org/show_bug.cgi?id=138427 on JavaScriptCore and https://code.google.com/p/v8/issues/detail?id=3678 on V8.

I don't have IE to test what Chakra does here, unfortunately.

Comment 11

[Emanuel Hoogeveen [:ehoogeveen]]

IE11 (after setting my time zone to UTC London):

(new Date(-3600000)).toString(); => "Wed Dec 31 1969 23:00:00 GMT+0000 (GMT Standard Time)"
(new Date(0)).toString(); => "Thu Jan 01 1970 00:00:00 GMT+0000 (GMT Standard Time)"
(new Date(-3600000)).toUTCString(); => "Wed, 31 Dec 1969 23:00:00 GMT"
(new Date(0)).toUTCString(); => "Thu, 01 Jan 1970 00:00:00 GMT"

Oddly I can't seem to get it to display (BST) even if I change my date back to before the switchover - perhaps it requires a reboot. Wilson, why are you still getting BST when summer time has ended?

Comment 12

[André Bargull [:anba]]

Did Europe/London observe DST in 1970 or was the timezone offset just shifted to +01:00? If I understand the tzdata entries correctly, the timezone offset was shifted. That means for ES6:
---
+(new Date(1970, 0, 1))
=> 20.3.2.1 Date, steps p-q
=> Let finalDate be MakeDate(MakeDay(1970, 0, 1), MakeTime(0, 0, 0, 0)).
=> Let finalDate be MakeDate(0, 0).
=> Let finalDate be 0.
=> TimeClip(UTC( 0 ))

UTC( 0 )
=> 0 – LocalTZA – DaylightSavingTA(0 – LocalTZA)
  with LocalTZA = 0 for Europe/London (LocalTZA does not depend on the input time!)
=> 0 – 0 – DaylightSavingTA(0 – 0)

DaylightSavingTA(0)
=> Daylight saving was not observed at utc=0, so DaylightSavingTA(0) returns 0 for Europe/London.

=> UTC( 0 ) = 0 – DaylightSavingTA(0) = 0 - 0 = 0

=> TimeClip(UTC( 0 )) = 0
---

That means "+(new Date(1970, 0, 1))" is expected to return 0. ES5 seems to allow/require(?) to return -3600000.

Probably the ES6 text should specify how to handle the case when the current timezone offset (LocalTZA) is different from the timezone offset at the time `t` when DaylightSavingTA(t) is requested.