--- title: Time Zones and Rocket Ships teaser: Rocket launches show us that we can know that two future events will be simultaneous, or what the local time will be, but not both. tags: web,rails,ruby author: Joël Quenneville published_on: 2022-12-06 --- 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][tzdata] (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]. [tzdata]: https://www.iana.org/time-zones [tzinfo gem]: https://github.com/tzinfo/tzinfo ## 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!