On 14/01/2023 16:32, Tim Cross wrote:
If org was to add TZ capabilities to timestamps, the underlying format
would have to be UTC.
...
can change based on various criteria, including political whims
(e.g. Australia eastern DST transition date was changed in 2000 because
Sydney hosted the Olympics that year).
Due to this particular reason storage format for significant fraction of
future timestamps (but not always) must not be in UTC
2024-01-14 Sun 21:14:58 ACS (+0930, Australia/Darwin)
is not the same as
2024-01-14 Sun 11:45:58 UTC (+0000, Z)
despite currently it is.
Depending on use case the same particular fields of timestamp may be
authoritative or derived for user convenience from other data.
UNIX timestamps in seconds in UTC timezone almost unavoidable will be
used underneath, but operations like "start of next day" require
non-trivial computations to find if time zone offset changes in between.
