5

There are many warnings out there about not using new Date(string) (or the equivalent Date.parse(string) in javascript because of browser inconsistencies. MDN has this to say:

It is not recommended to use Date.parse as until ES5, parsing of strings was entirely implementation dependent. There are still many differences in how different hosts parse date strings, therefore date strings should be manually parsed (a library can help if many different formats are to be accommodated).

However when you read on, most of the warnings about implementation-specific behaviour seem to be for these scenarios:

  • Old browsers (like, pre-ES5 old)
  • Non-ISO 8601 inputs (e.g. "March 6th 2015")
  • Incomplete ISO 8601 inputs (e.g. "2015-06-03", without the time or timezone)

What I would like to know is, given these two assumptions:

  • Modern browsers (say, anything from 2020 onwards)
  • Full ISO 8601 inputs (e.g. "2021-11-26T23:04:00.778Z")

Can I reliably use new Date(string)?

Cam Jackson
  • 11,860
  • 8
  • 45
  • 78
  • Have a look at the excellent [What are valid Date Time Strings in JavaScript?](https://stackoverflow.com/q/51715259/1048572) – Bergi Nov 27 '21 at 02:00

2 Answers2

2

Yes. The format of acceptable Date strings in JavaScript is standardized:

ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 calendar date extended format. The format is as follows:

    YYYY-MM-DDTHH:mm:ss.sssZ

From ECMAScript current draft under the section heading " Date Time String Format".

This is the only standard for parsing date strings presented in the spec and hence the aim of date libraries will be to format dates into this format before calling new Date or Date.parse. I can't comment on what the "simplification" of the ISO standard is, but the format asked about in the post matches that of the [ECMAScript] standard.

Note the standard continues on to state date only forms

YYYY
YYYY-MM
YYYY-MM-DD

are accepted and that time formats, optionally followed by a UTC offset, of

THH:mm
THH:mm:ss
THH:mm:ss.sss

may be used following the date component.

traktor
  • 17,588
  • 4
  • 32
  • 53
  • 2
    "*I can't comment on what the "simplification" of the ISO standard is*" - we got [What is simplified in ECMAScript 5 date format compared to ISO 8601](https://stackoverflow.com/q/45688749/1048572) on that :-) – Bergi Nov 27 '21 at 01:57
  • 1
    It's not the only format supported, implementations must also parse the formats produced by [*toString*](https://262.ecma-international.org/#sec-date.prototype.tostring) and [*toUTCString*](https://262.ecma-international.org/#sec-date.prototype.toutcstring) which are also standardised by [*ECMA-262*](https://262.ecma-international.org/#sec-date.parse). ;-) – RobG Nov 27 '21 at 05:50
  • 1
    @RobG The references to `toString` and `toUTCString` in the last paragraph of the "Date Time String Format" section of the spec require an implementation to be able to parse its own date format strings but not also those of another implementation. [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#fall-back_to_implementation-specific_date_formats) repeats the same thing. However, `toString` and `toDateString` being standardized brings into question the accuracy of the Date Times String Format section itself. Perhaps it should be updated :) – traktor Nov 27 '21 at 11:42
1

Yes, it is reliable to use ISO 8601 inputs to new Date.

As the documentation you quoted indicated, this was standardised with ES5, and according to MDN's compatibility table, Internet Exploder 8 (RIP) was the last browser not to support it.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • 1
    Well, only the two specific ISO formats supported by ECMA-262, not ISO 8601 formats in general. :-) – RobG Nov 27 '21 at 05:53