IANA canonicality and time zones equality

[Yqwed]

Hi Justin!

I am Almaz, I do time zone updates on Android. Just a few thoughts:

There is no such thing as a canonical time zone ID according to IANA [1]. So "canonical in Firefox (from IANA)"
and "IANA Canonicalization" mentioned in [2] are not really accurate.

From a practical perspective I agree that it is better to not do any sort of canonicalizations or links following in
the factory methods as their behaviour should be identical modulo actual Olson ID used there, which
unfortunately might be exposed in a string representation of a date/time object.
Also, as it takes a while for real world devices to receive the latest TZDB release, using the "newest" ID
as Firefox does might not be safe as it can be treated as invalid on the receiving side.

Equality is tricky: according to IANA relationship between Asia/Kolkata and Asia/Calcutta [3] is the same as
Europe/Berlin and Europe/Oslo [4]. Will Temporal.TimeZone.from('Europe/Berlin').equals('Europe/Oslo');
return true? If yes, won't it be surprising for developers? If not, how equality will be defined?

Thanks,
Almaz

[1] https://mm.icann.org/pipermail/tz/2022-August/031889.html
[2] https://github.com/justingrant/proposal-canonical-tz/blob/main/README.md
[3] https://github.com/eggert/tz/blob/c759f632702b2db2645f733e3574469fc20ee9c3/backward#L301
[4] https://github.com/eggert/tz/blob/c759f632702b2db2645f733e3574469fc20ee9c3/backward#L231

[justingrant]

Almaz you're the first person (other than me) filing an issue in our brand-new proposal repo. Welcome! 👋

It's great to connect with you because I'm sure that your practical experience with time zones on Android will be helpful as this proposal evolves.

There is no such thing as a canonical time zone ID according to IANA [1]. So "canonical in Firefox (from IANA)"
and "IANA Canonicalization" mentioned in [2] are not really accurate.

You're absolutely correct that we need to more precisely define what "canonical time zone identifier" means in ECMAScript. Creating the text for this definition is part of Step 4 as described in the README. I opened #8 for discussion. Feedback welcome!

Equality is tricky: according to IANA relationship between Asia/Kolkata and Asia/Calcutta [3] is the same as
Europe/Berlin and Europe/Oslo [4]. Will Temporal.TimeZone.from('Europe/Berlin').equals('Europe/Oslo');
return true? If yes, won't it be surprising for developers? If not, how equality will be defined?

Equality, at least as how we're thinking about it at the earliest stages of this proposal (can change with feedback) is that two time zones are considered equal if their canonical identifiers are identical. There's already a TimeZoneEquals abstract operation in the Temporal spec that compares the IDs of two time zones. This proposal would change its behavior to call CanonicalizeTimeZoneName first and then compare the results for string equality.

Conceptually, we're thinking of "equality" as meaning "These time zones can be considered the same, both now and in the future". There may be some edge cases where this certainty isn't absolute, like America/Montreal, which is not a Zone in zone.tab but could in the future stop being equal to America/Toronto -- see #9. But we could potentially solve this by changing our canonicalization definition to also include backzone. Needs more research.

Does this sound OK to you?

From a practical perspective I agree that it is better to not do any sort of canonicalizations or links following in
the factory methods as their behaviour should be identical modulo actual Olson ID used there, which
unfortunately might be exposed in a string representation of a date/time object.

This feedback is very good to hear, because retaining (un-canonicalized) IDs when storing time zone objects in memory (and when serializing them) is probably the largest change in this proposal and the one where I suspect people will have the most questions about whether it's the right direction to take.

Also, as it takes a while for real world devices to receive the latest TZDB release, using the "newest" ID
as Firefox does might not be safe as it can be treated as invalid on the receiving side.

Yep, I've also seen this problem reported in other environments too. I opened #6 to discuss this problem further. If you have feedback about the ideas discussed there, I'd be grateful to hear it.

[Yqwed]

Sorry for the late reply.

These time zones can be considered the same, both now and in the future

Is it for renaming only? Like Calcutta/Kolkata and Kiev/Kyiv? That's probably fine but please check that all Links can easily be segregated by that rule. Maybe it shouldn't be called canonicalisation because in ICU it would do different thing, but that's up to you.

Once you come up with strict definitions, please send it to IANA mailing list for review - there are people more experienced than me and their opinion will be valuable.

[justingrant]

These time zones can be considered the same, both now and in the future

Is it for renaming only? Like Calcutta/Kolkata and Kiev/Kyiv?

Yes.

Maybe it shouldn't be called canonicalisation because in ICU it would do different thing, but that's up to you.

Yep. Our latest PRs call it "primary time zone identifier" and "non-primary time zone identifier" and avoid the term canonicalization in the spec completely.

Once you come up with strict definitions, please send it to IANA mailing list for review - there are people more experienced than me and their opinion will be valuable.

👍