1

here is the following code snippet:

  date2 = new Date(1518, 8, 6, 0, 0, 0, 0);
  console.log(date2);

which I expect to return:

1518-09-06T00:00:00.000Z

but instead of, the console.log returns:

1518-09-05T22:43:40.000Z

What am I missing here?

EDIT: It seems, the problem is related to node.js, the problem occured when I run the code with node.

If I run it in Chrome Dev Tools console, the result is as expected:

Fri Sep 06 1518 00:00:00 GMT+0116 (Central European Summer Time)
AndrasU
  • 33
  • 7
  • I run the code with node.js, locally; now tried with Chrome developer tools console, there it works as expected... edited the original post according to this – AndrasU Dec 09 '18 at 17:16
  • 1
    [*Central European Summer Time*](https://en.wikipedia.org/wiki/Summer_Time_in_Europe) was not being observed anywhere in 1518, so why do you expect that result? See [*Browsers, time zones, Chrome 67 Error*](https://stackoverflow.com/questions/50609860/browsers-time-zones-chrome-67-error). The two timestamps are only 20 seconds apart, and since seconds can't be represented in standard offset notation, that's as close as they can get. – RobG Dec 09 '18 at 22:48
  • 1
    PS. 1:16:20 is the local meantime offset for Budapest, Hungary. – RobG Dec 09 '18 at 23:10

1 Answers1

2

The MDN documentation for Date includes this note:

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.

In other words, the arguments you passed represent 1518-09-06 00:00:00 in your local timezone, which corresponds to 1518-09-05 22:43:40 in UTC. It's the same moment in time, just represented in different timezones.

melpomene
  • 84,125
  • 8
  • 85
  • 148
  • There seems to be something more going on here. – Sami Hult Dec 09 '18 at 17:22
  • oh, yes, that's it...:-) It seems I have to check node.js documentation... – AndrasU Dec 09 '18 at 17:26
  • @SamiHult What do you mean? – melpomene Dec 09 '18 at 17:26
  • Different implementations seem to handle the timezone in surprising ways. On my computer (EEST) Chrome yields timezone GMT+0139 and Node 8 yields GMT+0300 (correctly). Also, GMT+0116 is *not* CEST. – Sami Hult Dec 09 '18 at 17:29
  • I mean why the local node.js handles Date differently than local Chrome – AndrasU Dec 09 '18 at 17:29
  • @SamiHult I assume it has to do with the year being 1518, so you have changes in the local calendar to deal with. – melpomene Dec 09 '18 at 17:30
  • Perhaps. If tzinfo database for example is used, somewhat reasonably timezones can be tracked back a long way - but they are not meant to be *relied* on, not before 1970. – Sami Hult Dec 09 '18 at 17:32
  • I can't easily find any source that satisfactorily explains this phenomenon. It looks like it might be defendable to add a warning to your answer about `Date` constructor doing some shady guesswork regarding the timezone. For the future generations :) – Sami Hult Dec 09 '18 at 17:38
  • @SamiHult—there is nothing weird about the Date constructor. Dates are extremely simple objects, they are just a time value offset from the epoch. There are differences in how that offset is translated into local time. Historic times are not simple, most of the current timezones did not exist before 1900, and many didn't exist before 1950. – RobG Dec 09 '18 at 22:38
  • @RobG This much is clear to me - I've been working quite much with times and timezones lately. What is odd is that I don't seem to find any good specification of how times in the past should be interpreted, which is probably the reason that the implementations vary so much. And just saying, Date objects are implied to work in the (current) local timezone, not to guess which *historical* timezone the poor programmer means. A time point from 1518 presented in the *current environment's timezone* would be equally valid, but - I think - more like how the behaviour's described in the documentation. – Sami Hult Dec 09 '18 at 23:05
  • @RobG If you can point me to a direction of The Specification, I would be much obliged :) – Sami Hult Dec 09 '18 at 23:06
  • @SamiHult—[*§20.3 Date Objects*](http://ecma-international.org/ecma-262/9.0/#sec-date-objects). You can also try [*MDN: Date*](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date), which isn't normative but is very helpful. ;-) – RobG Dec 09 '18 at 23:14
  • @RobG I have familiarised myself with the passage, especially "20.3.1.7 Local Time Zone Adjustment". *"An implementation of ECMAScript is expected to determine the local time zone adjustment. The local time zone adjustment is a value LocalTZA measured in milliseconds which when added to UTC represents the local standard time."* This does tell us *where* but not *when*. – Sami Hult Dec 09 '18 at 23:17
  • @SamiHult—the when is on the date, so for 6 Sep 1518. Until recently, implementations were expected to use current timezone offsets and rules as if they'd always existed (so CEST in 1518 was expected). However, recently they've been expected to make best attempts to observe historic rules, which works for modern history but becomes increasingly fraught the further back you go. – RobG Dec 09 '18 at 23:25
  • @RobG This was new to me and I thank you for the conversation. I also notice that I was referring to an outdated specification. The current one clearly states that *"The local political rules for standard time and daylight saving time in effect at t should be used to determine the result--"* – Sami Hult Dec 09 '18 at 23:32
  • @SamiHult—ECMA-262 is currently being updated every year. The current draft is at [*https://tc39.github.io/ecma262/*](https://tc39.github.io/ecma262/), the editions are published by ECMA International at [*http://ecma-international.org/publications/standards/Ecma-262.htm*](http://ecma-international.org/publications/standards/Ecma-262.htm). The github home page is at [*https://github.com/tc39/ecma262*](https://github.com/tc39/ecma262), which also has a mailing list if you want to participate or just see what's being discussed. Happy reading. :-) – RobG Dec 09 '18 at 23:37