Technically, if you store a ZonedDateTime that's in the future, it doesn't translate to a unique PlainDateTime (or Instant, if you store it as an ISO string); you need to add the version of the time zone database that was current when it was stored.
Advantages:
An example use case would be to store a ZonedDateTime, with the associated PlainDateTime cached, and the tzdata version. If the tzdata version changes, the cached PlainDateTime would be updated.
Another use case would be to compare the versions of the time zone data between client and server, to make sure that date operations are consistent if both client and server perform them.
Concerns:
There is no requirement for implementations to provide time zone data based on "the" time zone database, or any time zone data at all other than UTC, so a meaningful version is not always possible.
Exposing this information is a browser fingerprinting concern.
Summary of discussion at https://github.com/tc39/proposal-temporal/issues/1317:
Technically, if you store a ZonedDateTime that's in the future, it doesn't translate to a unique PlainDateTime (or Instant, if you store it as an ISO string); you need to add the version of the time zone database that was current when it was stored.
Advantages:
An example use case would be to store a ZonedDateTime, with the associated PlainDateTime cached, and the tzdata version. If the tzdata version changes, the cached PlainDateTime would be updated.
Another use case would be to compare the versions of the time zone data between client and server, to make sure that date operations are consistent if both client and server perform them.
Concerns:
There is no requirement for implementations to provide time zone data based on "the" time zone database, or any time zone data at all other than UTC, so a meaningful version is not always possible.
Exposing this information is a browser fingerprinting concern.
Prior art:
timezone_version_get()tzdatalibrary for Python hastzdata.IANA_VERSION.Constraints / corner cases:
TBD