On 07/12/2023 21:22, John Hasler wrote:
Databases should never store local time.
I am anticipating a new branch of hot discussion.
There are exceptions when storing UTC instead of local time leads to
undesired consequences.
Planned (future) events may be bound namely to local time. So if
timezone offset rules are changed due to new administrative regulations
then UTC timestamp becomes invalid. I do not mean regular spring and
fall time transitions related to DST. It may be decided to cancel or to
introduce DST, to shift dates when it is effective, to change time
offset for some territory. 10:00am local time remains 10:00am despite
before a new bill it is 15:00 UTC and it will be 14:00 UTC after. This
is a case for various calendar applications.
Historical documents specify local time. Time zone database may contain
incorrect data. Fixing TZ DB should not change local time for the stored
event.
Additional data may be required when local time is stored: time zone
identifier, disambiguation rule in the case of backward time transition
close to the event time, location for the case that existing time zone
will be split.
Despite calculation may be performed using UTC timestamps, local time is
definitive in these cases.