0

When converting a date string in the format "YYYY-mm-dd" to a Date object in JavaScript, I'm seeing an inconsistency in the output that I don't understand. I get different times when a single-digit day of month is preceded with a zero. I'm hoping someone can explain this to me.

Here is a console snippet to show what I mean, the first one being the inconsistent case:

d = new Date('2020-01-09');
Wed Jan 08 2020 19:00:00 GMT-0500 (Eastern Standard Time)

d = new Date('2020-01-9');
Thu Jan 09 2020 00:00:00 GMT-0500 (Eastern Standard Time)

d = new Date('2020-1-9');
Thu Jan 09 2020 00:00:00 GMT-0500 (Eastern Standard Time)

d = new Date('2020-01-019');
Sun Jan 19 2020 00:00:00 GMT-0500 (Eastern Standard Time)

d = new Date('2020-01-09 EST');
Thu Jan 09 2020 00:00:00 GMT-0500 (Eastern Standard Time)

So when the day is two digits and the first one a zero, it gives me a time that is five hours earlier, notably the same offset as the time zone. Preceding zeroes on two digit days make no difference, nor does preceding the date.

Note also the last line, where I use the same format but tack on the time zone as well. That seems to correct the problem.

Could somebody explain why this is happening?

Jacob Ewing
  • 770
  • 7
  • 22
  • 1
    The `Date` constructor expects the string to be in RFC 2822 format. None of these are in that format. If it isn't, your results will be inconsistent. –  Jan 02 '20 at 20:26
  • 2
    The result that you get, if you pass a string to the constructor of `new Date` that is not in the `ISO 8601` format, is not defined. So should not expect anything reliable or explainable in that case. – t.niese Jan 02 '20 at 20:27
  • Also see [*Why does Date.parse give incorrect results?*](https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results) – RobG Jan 03 '20 at 01:08

1 Answers1

2

According to the Date.parse() documentation, if you're passing a non-standard Date String, then the parsing might assume UTC Time zone, which is why your time is showing a 5 hour difference

You're seeing inconsistency because the spec doesn't have anything concrete on how to handle these invalid Strings; it's left to browser implementation. This does also apply to the previous point about assuming UTC Time zone

If the String does not conform to the standard format the function may fall back to any implementation–specific heuristics or implementation–specific parsing algorithm.

Shiny
  • 4,945
  • 3
  • 17
  • 33
  • That makes sense - but why then does it work with the other formats I plugged in? – Jacob Ewing Jan 02 '20 at 20:31
  • 2
    @JacobEwing You may get different results in different browsers when the format isn't consistent with RFC 2822. The spec says "it needs to be in RFC2822, if it isn't, its left to each individual implementation how it wants to handle it." –  Jan 02 '20 at 20:32
  • @Amy—please don't focus on RFC2822. ECMA-262 specifies two exact formats, one is RFC2822 compliant but it does not, in general, support all possible RFC2822 formats in the same way that ECMA-262 also supports one precise ISO 8601 compliant format, but does not support ISO 8601 in general (and is inconsistent with ISO 8601 in regard to date–only forms). – RobG Jan 02 '20 at 22:37