0

I know that creating a date from string is usually a bad idea, but still, this caught my attention: adding a space before or after the date string can affect the created date value.

console.log([

  new Date('2019-03'),      // 2019-03-01T00:00:00.000Z
  new Date('2019-03 '),     // 2019-02-28T23:00:00.000Z
  new Date(' 2019-03'),     // 2019-02-28T23:00:00.000Z

  new Date('2019-03-05'),   // 2019-03-05T00:00:00.000Z
  new Date('2019-03-05 '),  // 2019-03-04T23:00:00.000Z

  new Date('2019/04/16'),   // 2019-04-15T22:00:00.000Z
  new Date('2019/04/16 '),  // 2019-04-15T22:00:00.000Z
  
]);

According to the Date docs, new Date(<string>) invokes Date.parse to get the time value. Besides that, the docs don't seem to give any pointers to what happens to untrimmed strings.

I'm really stuck on this one! Why do space affect the time? It's programming, not general relativity!

The console logs above where produced by a Chrome 73 browser running a v8 engine in Berlin (UTC+1)

Nino Filiu
  • 16,660
  • 11
  • 54
  • 84
  • 2
    Looks like only strict formats are considered as UTC times, and sloppy formats (such as including a space) are parsed according to the local timezone. – Bergi Mar 26 '19 at 20:34
  • That seems indeed to be the answer. Still, that's a very unintuitive design – Nino Filiu Mar 26 '19 at 20:41
  • Why would spaces in date strings be considered *intuitive*? Validate your input first. Note that not all of those formats will work consistently cross browser also – charlietfl Mar 26 '19 at 20:46
  • 1
    It's not the spaces that are unintuitive, it's the fact that JS decides to chose a different time zone based on the sloppiness of the input. They shouldn't be linked together IMO – Nino Filiu Mar 26 '19 at 20:49
  • 1
    @NinoFiliu Well yes, the design of the parser isn't really good, but that how it is and can hardly be changed for webcompat reasons. And this is the exact (and only) reason why using `Date.parse` to create dates from strings is usually a bad idea in JavaScript (that is, unless you include a timezone signifier explicitly). – Bergi Mar 26 '19 at 20:57
  • The normative documentation is [*ECMA-262*](http://ecma-international.org/ecma-262/9.0/). MDN is a very useful resource, but it's just a public wiki, not an authority. – RobG Mar 27 '19 at 00:32
  • @NinoFiliu—there are 3 formats for which parsing is specified. Anything else is implementation dependent, so you are at the whim of the developers. – RobG Mar 27 '19 at 06:12

1 Answers1

2

From the specification (paragraph 20.3.3.2):

The function first attempts to parse the format of the String according to the rules (including extended years) called out in Date Time String Format (20.3.1.16). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

So, when a space is added, the string does not conform to the Date Time String Format and the parser falls back to implementation-specific algorithm. Like Bergi writes, this takes the local timezone in account.

edwin
  • 2,643
  • 20
  • 17
  • "*… this takes the local timezone in account*" that is not part of the specification. 2019-03-05 should be parsed as local, but the OP's results show it's being parsed as UTC. So even when the string does conform to ECMA-262, some parsers still get it wrong. And if it doesn't conform to ECMA-262, it's not necessarily parsed as local or UTC, it's up to the implementation. ;-) – RobG Mar 27 '19 at 06:22