While the physical phenomenon of time always moves forward, local time is capricious. It can jump forwards and backwards, skip some numbers entirely and repeat others. Worse still, local time changes can happen arbitrarily. This can make it really hard to work with times in the future.
Scheduling an event with absolute time
For example, let’s say the USA and EU are both launching rockets from their
launchpads at Cape Canaveral, Florida and Guiana Space Center, French Guiana
respectively. Both launches are scheduled for the UNIX timestamp 1637168400
so we know the two launches will happen simultaneously.
What we don’t know is what the local clocks will read at launch time. The clocks
will probably read 12:00 in Florida and 14:00 in French Guiana but that
would change if the local governments decide to switch time zones or mess with
daylight savings rules (this happens more than you’d think, sometimes at the
last minute).
Scheduling at local time
That’s not great for local people who want to set an alarm for the launch, so
instead the launches could be scheduled for 12:00 and 14:00 local time. Now
we know for sure what the clocks will read when the launch happens but we don’t
know exactly when the launch will happen. Will both rockets lift off at the same
time? Will one leave before the other? 🤷♂️ Both scenarios are
possible depending on what changes, if any, happen to the local time format.
Future events defined in local time cannot be meaningfully compared with each
other.
The Olson database
Computers deal with this problem by having a big database of zones (often called the Olson database or tzdata) that tells us what local time formats were in the past, and our best knowledge of what they should be in the future. It looks kind of like this:
| Zone | Start | Stop | Offset |
|---|---|---|---|
America/New_York |
March 13, 2022 | Nov 6, 2022 | -4 |
America/New_York |
Nov 6, 2022 | -5 |
We can use that to convert a UTC value into local time or vice versa for moments in the past as well as our best guess as to what they will be in the future. Note that when it comes to the future, this database is not prescriptive! It describes what we think the offsets will be but local authorities could (and do!) change that reality at any time.
In Ruby, we get commonly get access to this data with the tzinfo gem.
Don’t trust local time
If you want to guarantee that an event will take place at a fixed point in time, use UTC and avoid storing a value as a local time. Local times are always fluctuating relative to UTC and each other. Generally, they should only be used as a view-level concern to localize data for human consumption.
If you use local time as a source of truth, be aware that your system knows what clocks will read at that location, but not when the event happens. Now you know the difference!
