On 15/01/2023 03:30, Tim Cross wrote:
The UTC time stays the same, but the
meeting time for me changes twice per year (moving forward/backward an
hour).
Meeting time remains the same expressed as local time (15:00), but
alternates between 04:00 and 05:00 UTC. So repeating schedule can not be
stored as UTC, instead UTC timestamp should be calculated from local
time for each date. (Even libc can do it while you work with single
timezone.) It is OK to store in UTC already passed events, but local
time still may be more compact and user friendly.
Actually I am trying to draw attention to a more tricky case when
timestamp stored as local time is even more important. Event time is
bound to local time, and timezone database changed due to new rules for
this time zone: the government decided to cancel or introduce DST
transitions or to extend/shorten interval when daylight saving time is
active. For a timezone without DST time offset may be changed as well.
While timezone database is stable, you can calculate UTC timestamps for
any moments expressed in local time. When new rules are published some
future UTC timestamps become invalid. If you know local time, you may
update UTC timestamps. If you store just UTC timestamp you have a trouble.
Paul Eggert provided an example of updating time transition history, so
what is authoritative: local time or UTC, applies to the past as well.
However I do not agree with Paul completely. It is necessary to decide
for each timestamp, what is the primary data, time offset (so timezone
identifier should be updated) or local time (so time offset should be
updated keeping timezone identifier).
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#30
Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list
Thu, 14 Apr 2022 15:46:58 -0700
Again, that depends on the application. It's typically wrong to store an
old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because
there is no standard for what "Europe/Lisbon" means. If you update your
copy of TZDB, or interpret such a timestamp on another computer, that
can change the interpretation of such a timestamp. In this particular
case, a change in TZDB release 2021b altered the interpretation of this
old timestamp because we discovered that DST was observed in 1950 in
Portugal.
If you want to keep the TZDB identifier for advice about how to
interpret dates relative to a timestamp, that's fine. But you should
keep the UT offset in addition to the TZDB identifier, if you want your
app to be fully accurate and useful. For example, you should store
"1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by
TZDB release 2021a, so that when you interpret the timestamp in release
2021b you'll have an idea of what you're dealing with.
So keeping redundant information may be crucial to get warnings that
some timestamps need to be reviewed.
