7

What's the difference between this date format:

"2021-01-01T00:00:00.000Z"

and this one:

"2021-01-01T00:00:00+00:00"

Are they both valid ISO formats? When I call new Date().toISOString() in JavaScript, I get the first one.

For some reason, I'm having trouble finding a definitive answer on this.

jbyrd
  • 5,287
  • 7
  • 52
  • 86

2 Answers2

6

From Wikipedia:

An offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00".

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • Ah there it is, yes I see it now - thank you! – jbyrd Jun 21 '21 at 15:45
  • 2
    Note: "-00:00" may have a different meaning (IIRC a RFC defined it for "unknown timezone", but keeping compatible with ISO notation, as workaround) – Giacomo Catenazzi Jun 21 '21 at 18:01
  • 1
    While Wikipedia is useful for general information, it is not an authority and should not be quoted as such. When discussing ISO date and time standards, [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) is the only authoritative reference. In regard to parsing of timestamps in ECMAScript, [*ECMA-262*](https://262.ecma-international.org/#sec-date-time-string-format) is the authoritative reference, where "Z" and "+00:00" are equivalent, parsing of any other format (including +0000 and +00) is implementation dependent. – RobG Jun 21 '21 at 23:50
  • @GiacomoCatenazzi—that is a truely awful design feature. If the timezone is unknown, the offset should be omitted, which is compatible with ISO 8601. – RobG Jun 22 '21 at 00:24
  • @RobG: I agree about awfulness, but I see also few reasons: human: it requires time offset, so programmers should handle it, and they will tend not to forget or make shortcuts (so you will use such feature only when converting from old to new protocols). program: in program you implement only one path. In any case such RFC is ugly and inconsistent (confusing/mixing both "time offset" and "time zone"), the good: it offer a sensible ISO 8601 like dates like we see now (ISO 8601 has many more variants and special cases, IIRC) and a clear (and public) grammar for dates. – Giacomo Catenazzi Jun 22 '21 at 05:16
  • 1
    @GiacomoCatenazzi—there is much confusion around date and time terminoology. As you say, ±HHmm is an offset, not a timezone. Similarly, "America/New_York" isn't a timezone either, it's a location (per IANA). And "en-GB" is a language code, not a "locale" (per EMCA-402). No wonder people are confused. Hopefully the pedants can chip away at misuse of terms and maybe one day set the record straight. I spent years railing agains the use of "context" for *this*, my small contribution to correct usage. :-) – RobG Jun 22 '21 at 10:23
0

ECMA-262 defines a "string interchange format" that is generated by toISOString and must also be parsed by the built–in parser. It states:

Z is the UTC offset representation specified as "Z" (for UTC with no offset) or an offset of either "+" or "-" followed by a time expression HH:mm (indicating local time ahead of or behind UTC, respectively)

So while toISOString produces "Z", the parser will also accept "+00:00" and "-00:00". Correct parsing of any other format is implementation dependent (and hence unreliable).

RobG
  • 142,382
  • 31
  • 172
  • 209