I have always wondered why breaking the timestamp (in UTC) and the timezone into two separate data points and storing both is not the accepted solution. It appears like the cleanest solution to me.
You can't accurately convert future local times to UTC timestamps yet, as that conversion changes when timezones change.
Let's say we schedule a meeting for next year at 15:00 local time in SF. You store that as an UTC timestamp of 2025-08-24 22:00 and America/Los_Angeles timezone. Now, imagine California decides to abolish daylight savings time and stay on UTC-8 next year. Our meeting time, agreed upon in local time, is now actually for 23:00 UTC.
Wow thanks for sharing this, this certainly is a use case not covered by the system I proposed. I imagine this will require versioning of the timezone so we can translate our America/Los_Angeles v1.0 timestamp to America/Los_Angeles v2.0.
Two different implementations might make two different local times out of that, e.g. due to not being aware of changing DST/timezone policies. Hence the recommendation of separating between user/clock/calendar time (which must be exact to a human) and absolute/relative timestamps (which must be exact to a computer).
From my experience, it certainly is. Easy to tell time in sequence as well as local time then. When daylight savings hits you can still calculate well, and can quickly get real time for hours worked out drive time for freight across time zones to follow the hours of service rules.
