6

I found an interesting quirk in Chrome when parsing strings as dates. These strings parse the same way:

new Date("2020 01 01")
=> Wed Jan 01 2020 00:00:00 GMT-0500 (GMT-05:00)

new Date("2020-01 01")
=> Wed Jan 01 2020 00:00:00 GMT-0500 (GMT-05:00)

new Date("2020 01-01")
=> Wed Jan 01 2020 00:00:00 GMT-0500 (GMT-05:00)

But not this one, which comes back several hours behind:

new Date("2020-01-03")
=> Tue Dec 31 2019 19:00:00 GMT-0500 (GMT-05:00)

Here's a codepen with the same code.

Why does this happen?

Edit: this is Chrome 73.0.3683.103.

Edit2: In Node LTS, the problem is reversed:

> new Date("2020 01 01")
2020-01-01T05:00:00.000Z

> new Date("2020-01 01")
2020-01-01T05:00:00.000Z

> new Date("2020 01-01")
2020-01-01T05:00:00.000Z

but

> new Date("2020-01-01")
2020-01-01T00:00:00.000Z

In Safari 12.1, the first three are invalid:

new Date("2020 01 01")
=> Invalid Date

new Date("2020-01 01")
=> Invalid Date

new Date("2020 01-01")
=> Invalid Date

and the last one is also wrong!

new Date("2020-01-01")
=> Tue Dec 31 2019 19:00:00 GMT-0500 (EST)
Benjamin
  • 1,020
  • 11
  • 16
  • 1
    What browser and version are you using? There are only a few standardized date formats, the rest are implementation dependent. – 4castle Apr 15 '19 at 01:58
  • Subtraction maybe? 2020 - 1 = last day of 2019? – Jack Bashford Apr 15 '19 at 01:59
  • This is in the most recent Chrome, 73.0.3683.103. – Benjamin Apr 15 '19 at 02:00
  • It is funny, how did you get dec 31?? – wentjun Apr 15 '19 at 02:01
  • 1
    It is a Chrome-specific bug, I think. There are other weird behaviours in other engines. – Benjamin Apr 15 '19 at 02:02
  • I'll give you 1 more weird case: `new Date('2020-01-01')` and `new Date('2020-01-01 ')` give different result. – yqlim Apr 15 '19 at 02:05
  • 6
    "Doctor, it hurts when I do foo." "Well, stop doing foo!" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date "Note: parsing of date strings with the Date constructor (and Date.parse, they are equivalent) is strongly discouraged due to browser differences and inconsistencies. Support for RFC 2822 format strings is by convention only. Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local." – ceejayoz Apr 15 '19 at 02:07
  • 1
    Your first three examples give `Invalid date` in mobile Safari (maybe desktop as well?). There's no spec defining how to parse those dates so you can't rely on any particular result. – Lennholm Apr 15 '19 at 02:14
  • @ceejayoz ironically, even the one standard (that date-only dateStrings be treated as UTC) is also wrong – Benjamin Apr 15 '19 at 02:16
  • @Benjamin how is it _"wrong"_? When you have a date-only ISO 8601 formatted string, the browser interprets it as UTC. When you display it, it formats the date for your local timezone – Phil Apr 15 '19 at 02:59
  • 2
    @Phil—it might at least be called inconsistent, given that ECMAScript supports ISO 8601 parsing of other strings, but not date–only forms. That decision seems based on one person's [*commercial interests*](https://github.com/tc39/ecma262/issues/87), not common sense. – RobG Apr 15 '19 at 07:38

0 Answers0