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.