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

RESOLVED INVALID

Status

()

Core
JavaScript Engine
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: wilsonpage, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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
(Reporter)

Comment 1

3 years ago
Also Firefox: new Date(1965, 0, 1).getFullYear(); //=> 1964
Component: General → JavaScript Engine
Bug 830304 contains a WIP patch for this issue.
Wilson, what does "+new Date(1970, 0, 1)" return for you in Firefox and Chrome?  Are they both 18000000?
Flags: needinfo?(wilsonpage)
(Reporter)

Comment 4

3 years ago
(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
Flags: needinfo?(wilsonpage)
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()
Flags: needinfo?(wilsonpage)
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?
(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.
(Reporter)

Comment 8

3 years ago
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"
Flags: needinfo?(wilsonpage)
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
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.
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?
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.

Updated

3 years ago
Duplicate of this bug: 971795
You need to log in before you can comment on or make changes to this bug.