Time Zones and Rocket Ships

Joël Quenneville

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.

Space shuttle launching into space
Photo by NASA via Unsplash

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!