What are valid Date Time Strings in JavaScript?

Question

When using new Date or Date.parse in JavaScript, I cannot just pass arbitrary date formats. Depending on the format, I get a different date than I

Answer 1

So which date time formats should I use?

The general recommendation is to not use the built-in parser at all as it's unreliable, so the answer to "should" is "none". See Why does Date.parse give incorrect results?

However, as str says, you can likely use the format specified in ECMA-262 with a timezone: YYYY-MM-DDTHH:mm:ss.sssZ or YYYY-MM-DDTHH:mm:ss.sss±HH:mm, don't trust any other format.

Do all browser support the same formats?

No.

How do Mozilla Firefox, Google Chrome, Microsoft Internet Explorer, Microsoft Edge, and Apple Safari handle date time strings?

Differently. Anything other than the format in ECMA-262 is implementation dependent, and there are bugs in parsing the the ECMA-262 format.

What about Node.js?

Likely different again, see above.

Does it take the local date format into consideration? E.g. if I live in Switzerland and the date format is 30.07.2018, can I use new Date('30.07.2018')?

Maybe. Since it's not the standard format, parsing is implementation dependent, so maybe, maybe not.

Does it take the local time zone into consideration?

It uses the host timezone offset where the string is parsed as local and to generate the string displayed using local times. Otherwise it uses UTC (and the internal time value is UTC).

How can I get a date time string from a date object?

Date.parse.toString, or see Where can I find documentation on formatting a date in JavaScript?

How can I detect invalid date time strings?

One of the first 3 answers here should answer that.

How do date libraries like Moment.js handle date strings?

They parse them based on either a default or provided format. Read the source (e.g. fecha.js is a simple parser and formatter with well written, easy to follow code).

A parser isn't hard to write, but trying to guess the input format (as built-in parsers tend to do) is fraught, unreliable and inconsistent across implementations. So the parser should require the format to be provided unless the input string is in the parser's default format.

PS

There are changes to the formats of strings that implementations must support for parsing and formatting in ECMAScript 2019 (currently in draft), but I think the general advice to avoid the built–in parser will stand for some time yet.