Z designator (designating UTC) results in errors

When giving PlainDateTime a datetime string with time zone in brackets, the time zone is simply ignored:

Temporal.PlainDateTime.from('2022-02-07T10:30:00[Europe/Brussels]')

Temporal.PlainDateTime {repr: ‘Temporal.PlainDateTime <2022-02-07T10:30:00>’}

When giving PlainDateTime a datetime string with Z appended (UTC), an error occurs:

Temporal.PlainDateTime.from('2022-02-07T10:30:00Z')

ecmascript.mjs:1120 Uncaught RangeError: Z designator not supported for PlainDateTime at Object.ToTemporalDateTime (ecmascript.mjs:1120:20)

When giving ZonedDateTime a datetime string with time zone in brackets:

Temporal.ZonedDateTime.from('2022-02-07T10:30:00[Europe/Brussels]')

Temporal.ZonedDateTime {repr: ‘Temporal.ZonedDateTime <2022-02-07T10:30:00+01:00[Europe/Brussels]>’}

When giving ZonedDateTime a datetime string with Z appended (UTC), another error occurs:

Temporal.ZonedDateTime.from('2022-02-07T10:30:00Z')

ecmascript.mjs:322 Uncaught RangeError: Temporal.ZonedDateTime requires a time zone ID in brackets at Object.ParseTemporalZonedDateTimeString (ecmascript.mjs:322:33)

It is very common for programming languages to append Z on a datetime in UTC. My Elixir backend returns a string like '2022-02-07T10:30:00Z' and Temporal doesn’t seem to give me an easy way to parse it. I don’t see why time zones in brackets are allowed but not the Z designator.

[mathieuprog]

We’re working with IETF to standardize the time zone and calendar extensions to RFC 3339. Once the standard is approved, we’ll update the docs and error messages of polyfills.

That will take years right? The IETF mentions “JAVAZDT” to refer to the format Java Time (and Temporal) are using: https://www.ietf.org/archive/id/draft-ryzokuken-datetime-extended-02.html. I thought that maybe we can change ISO8601 to JAVAZDT in the error messages, and then replace it by the IETF standard.

Feel free to close this issue by the way, if it no longer requires attention. Thank you for all the clarifications!

[gilmoreorless]

UTC is an alias for Etc/UTC in the TZDB, so it is valid as part of that string. Although the new information that I learned while looking this up, is that it is listed in the backward file, which I believe means it’s not preferred, though I’m not 100% sure.

Fittingly there was a clarification update made to the documentation a couple of weeks ago. The description of backward now states:

The source file backward defines links for backward compatibility; it does not define zones. Although backward was originally designed to be optional, nowadays distributions typically use it and no great weight should be attached to whether a link is defined in backward or in some other file.