Normative: Canonicalise "GMT" to "UTC" #724
Conversation
tzdata 2022f using vanguard format made "GMT" a zone and "Etc/GMT" a link to "GMT". Rearguard format still has this the other way around, i.e. "Etc/GMT" is a zone and "GMT" a link to "Etc/GMT". Because we don't control if vanguard or rearguard format is used by an implementation, the `CanonicalizeTimeZoneName` operation should canonicalise both "Etc/GMT" and "GMT" to "UTC".
|
tzdata 2022f release notes mentioning this change: tzdata definitions for "Etc/GMT" and "GMT": |
|
Are you sure? From what I understand, GMT and UTC are semantically different and this mental model is propagated within Temporal (GMT being an actual human timezone and UTC being a constant zero value, quite like |
|
The current definition of CanonicalizeTimeZoneName is already canonicalising "Etc/GMT" to "UTC". This change is only ensuring that the canonicalisation is the same irrespective of whether the vanguard or the rearguard format is used. |
There was a problem hiding this comment.
Fair enough, I should've checked the spec diff first 🙈
Either way, pinging @ptomato @justingrant @sffc @gibson042 to discuss this if needed.
|
No discussion needed from my side. It's true that in some usages "GMT" is a time zone while "UTC" is the quantity, but the TZDB doesn't treat it like that: https://github.com/eggert/tz/blob/main/etcetera |
There was a problem hiding this comment.
It's true that in some usages "GMT" is a time zone while "UTC" is the quantity, but the TZDB doesn't treat it like that: https://github.com/eggert/tz/blob/main/etcetera
@ptomato can you elaborate? As far as I can tell, tzdata has and continues to differentiate GMT and UTC. But the conflation of them in ECMA-402 already exists, and I support making sure that it is at least consistent.
This exactly. I'm all for continuing to be consistent on the side of 402, but there's this semantic inconsistency between Temporal (which treats both as distinct timezones) and 402. At the very least, we should discuss if this is desirable or if we need to address this in either or both. |
I meant that TZDB contains a "UTC" time zone whereas some people use slightly different terminology and say that "GMT" is a time zone and "UTC" is not. It's true that they are separate time zones in the TZDB and the conflation of the two comes from ECMA-402's CanonicalizeTimeZone.
I clarified this in the ECMA-402 meeting, but for the record: in ECMA-402 implementations, new Temporal.TimeZone uses CanonicalizeTimeZone, so there is no discrepancy with Temporal. |
|
2022-11-03: TG2 consensus. |
tzdata 2022f using vanguard format made "GMT" a zone and "Etc/GMT" a link to "GMT". Rearguard format still has this the other way around, i.e. "Etc/GMT" is a zone and "GMT" a link to "Etc/GMT". Because we don't control if vanguard or rearguard format is used by an implementation, the
CanonicalizeTimeZoneNameoperation should canonicalise both "Etc/GMT" and "GMT" to "UTC".