Node: Incorrect output using Date() in UTC+1 timezone

[Hadis-Fard]

• Version: v10.7.0
• Platform: Windows 64 bit and Linux UB 17.10 x86_64 GNU/Linux

const YEAR_ONE = new Date(2000, 0, -730118); returns "0000-12-31T23:25:52.000Z" which doesn't seem right

tediousjs/tedious#767

[mscdex]

From https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date:

Note: Where Date is called as a constructor with more than one argument, the specified arguments represent local time. If UTC is desired, use new Date(Date.UTC(...)) with the same arguments.

new Date(Date.UTC(2000, 0, -730118)) in a REPL prints: 0001-01-01T00:00:00.000Z

[Hadis-Fard]

@mscdex the output of new Date(2000, 0, -730118) in v8.12.0 in windows 10 cmd terminal is 0000-12-31T23:00:00.000Z which represents the local time. However, the output in v10.7.0 is 0000-12-31T23:06:32.000Z which seems like a regression

[mscdex]

It does seem there is something amiss here. For me (EDT timezone) with this code:

new Date(2000, 0, -730118).toISOString()

Chrome 69, node v10.11.0, node master, and a node v8-canary build with V8 7.1 all return:

0001-01-01T04:56:02.000Z

while node v8.12.0, Firefox 62, and Edge 38 all return:

0001-01-01T05:00:00.000Z

/cc @nodejs/v8

[hashseed]

Bisected to this. I'd say it's intentional. I would be mildly surprised if the time of days until year 2000 is a clean multiple of days.

[hashseed]

If you compile V8 with v8_enable_i18n_support=false or the equivalent gyp flag, you would get the old result.

[jungshik]

Similar issues have been reported a number of times against Chrome. The reason for that strange-looking-offset is that ICU has the data for the pre-standard-timezone offset (Local Mean Time). The data for LMT offsets comes from the IANA timezone database the Ecma 262 spec refers to.

For instance, with timezonse set to Europe/Berlin, you'll have the following:

> new Date(2000, 0, -730118).toISOString()
0000-12-31T23:06:32.000Z

instead of 
0000-12-31T23:00:00.000Z

If you go to https://www.timeanddate.com/time/zone/germany/berlin and look up the timezone offset for Berlin in 1850, you'll see that the offset is 53m 28s instead of 1h. As a result, 0001-01-01T00:00 in Berlin time becomes 0000-12-31T23:06:32Z .

[jungshik]

53m 28s corresponds to 13.4050 ° E (Berlin's longitude).

[mj1856]

Yes, the values stem from LMT entries in the tzdb. But also, these changes are related to the ECMAScript spec changes from ECMAScript 5.1 section 15.9.1.8:

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.

to ECMAScript 2015 section 20.3.1.8:

An implementation dependent algorithm using best available information on time zones to determine the local daylight saving time adjustment DaylightSavingTA(t), measured in milliseconds. An implementation of ECMAScript is expected to make its best effort to determine the local daylight saving time adjustment.

NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database http://www.iana.org/time-zones/.

Also, the note at the end is what differentiates Edge from the others. Edge is using Windows time zone data rather than IANA for this particular operation, and Windows time zone data does not have LMT entries.

TL;DR: There is no regression. This is the desired behavior.

[Trott]

Consensus seems to be that this is not a bug. Closing.