Serializing and deserializing across changes to the timezone database

In https://github.com/whatwg/html/pull/6284 @anba brought up this concern:

I just wonder if calendar and time zones should get re-validated when deserialised, in case the supported calendars or time zones changed in some way. For example when serialising to disk and later deserialising from disk with a newer browser version, it's possible that some calendars or time zones are no longer supported or are canonicalised differently (only relevant for calendar identifiers).

I was initially leaning towards then maybe not supporting timezone serialization, but @hsivonen brought up some good points:

I think we should not prohibit serializing values that have attached time zones, because it would be bad to give Web developers an incentive to prefer UTC offset over cities in values that get serialized. UTC offset does not accomplish the same as a city even within one year in places that have daylight saving time, and more generally, user-perceived time zones over time are attached to political rules in a particular place and not to a particular offset.

I think we should explicitly cover the possibility of time zone canonicalization changing over time (Kiev to Kyiv, Calcutta to Kolkata, etc.) and the possibility of a time zone going away. In the case of canonicalization change, we can assume there to be data that enables re-canonicalization under the new rules.

I'm not sure what we should spec about time zones going away, but it seem unlikely enough that we shouldn't prohibit serialization due to that possibility.

In the scenario where we cannot recover we can probably reuse the existing "DataCloneError" DOMException.

Two questions come to mind:

1. What does TC39 think about this?
2. Who will specify the infrastructure to validate a serialized timezone and "correct" it when deserialization is requested?

cc @Ms2ger @ptomato @nicolo-ribaudo

Start with the linked WHATWG HTML PR 6284 and the cited TC39 discussion about serialized time zones, canonicalization, and unavailable identifiers. Resolve the two stated questions with the relevant standards groups, then specify the deserialization behavior and the failure condition, including whether DataCloneError is reused.