0

For my WebApp I'm writting unit-tests using Jest and my dev environment is IntelliJ Ultimate 2018.1.

In my unit-tests I need to create Date() from a String. My problem is that when I share this unit-test with my colleague it's not working because the Date(String) is returning a different date (he's using the same dev environment).

For example, In my evironment, when I execute new Date("2018-05-12T19:00:00") I get Sat May 12 2018 19:00:00 GMT+0200 (Romance Summer time)

When my colleague executes exactly the same line of code, he gets Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))

When I add a Z at the end of the date, like new Date("2018-05-12T19:00:00Z") I get Sat May 12 2018 21:00:00 GMT+0200 (Romance Summer time) and he gets the same date with Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))

Why do we get this 2 hours differences when using new Date("2018-05-12T19:00:00") ? We are on the same timezone.

Thanks for your help!

skyboyer
  • 22,209
  • 7
  • 57
  • 64
sebastien
  • 2,489
  • 5
  • 26
  • 47
  • 1
    Because the one browser interprets it as UTC and the other as the local timezone. But you found the solution already: put an explicit timezone on the string. – Bergi Jul 26 '18 at 12:35
  • My unit-tests are executed by Jest in IntelliJ. In believe the runtime environment is Node.js and not the Browser. In addition, why the timezone is different? Romance Summer Time and Paris/Madrid are the same timezone. – sebastien Jul 26 '18 at 13:08
  • I don't know Jest in particular, but it just shows that you and your colleague have different environments set up. – Bergi Jul 26 '18 at 13:16
  • Probably should be closed, see [*Why does Date.parse give incorrect results?*](https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results) But I like the comments and answers. :-) – RobG Jul 27 '18 at 00:29

1 Answers1

1

The older ECMAScript 5.1 Spec says in §15.9.1.15:

... The value of an absent time zone offset is "Z".

That means, if you don't specify an offset, it will assume you meant UTC.

Note that since this is the opposite of what ISO-8601 says, this is behavior has been changed in ECMAScript 2015 (6.0), which says in §20.3.1.16:

... If the time zone offset is absent, the date-time is interpreted as a local time.

Thus, it would seem that your colleague is executing the code through an older version of the JavaScript engine. Your string is being interpreted as local time per the newer spec, and theirs is being interpreted as UTC per the older spec. Since you said this is all through Node.js, they should simply upgrade to a newer version of Node.js.

I blogged about this behavior some time ago, if you'd like more details.

If you want to be resilient to older environments, consider parsing the date string yourself or with a library. There are many to choose from. In general, many people do not trust the string parser that comes attached to the Date object because it has changed over the years, has some implementation-specific behaviors, and still does silly things like assuming whole dates like "2018-07-26" should be interpreted as UTC instead of local time like ISO 8601 specifies.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575