Time Zones Are Hard
Tags: timezones
Published: 2021-10-05 17:04:39

I recently saw this on Twitter (hope it doesn't trigger any of you):

***NEW TIME ZONES!!!***

{% twitter 1444524436548296705 %}

## What's The Big Deal?

Imagine your application has users throughout Australia. They probably include people in the three red states in the right image above; where time is different during daylight saving time.

Let's also say your application has a feature that is very time-dependent. Let's say live TV recording. Users set recordings based on the schedule, in their local time. They expect not to miss recording their favorite shows.

Without updating and releasing a new version, everyone in the 3 states with a new time zone (only during DST) could miss recording a show at what is now 9pm.

## Problems Everywhere

There aren't many devices or applications or services that don't depend on correct time. DRM. Caching. Shoe launches. Events. Reminders.

I bet most people reading this have stored or fetched time that needed to be displayed in the correct time zone. Perhaps you didn't convert the time, but I bet it had to be converted somewhere downstream.

## Fix It

One solution to this problem is to do away with time zones altogether. As amazing as this would be for us, the chances are extremely low. If the United States can't convert to metric, there is basically no chance the entire world will ditch time zones.

Time for an engineering solution.

One possible solution is to only persist UTC (coordinated universal time) for any date-time. This gets us partway there. No users (ok, maybe a couple) will want to enter time in UTC, so we'll probably have to convert it. Here's where it gets tricky.

This amazing video by Computerphile puts it better than I could.

{% youtube -5wpm-gesOY %}

Let's see if we can find a solution.

## User First

Let's start with a user story:

*As a TV lover, I want to record my show in my local time, so that I can watch it later*

How do we know the local time? Location. There are a few different ways to know location: IP address, Geolocation API, GPS, asking where the user is, more. Now that we have the location, we must find the time zone.

This is the part I don't have a solid abstraction for. We must somehow map that location (latitude/longitude, city name, address) to the correct time zone. The most accurate is latitude/longitude, but we must fallback to a less precise location too.

Is it feasible to map the borders of each time zone and do our best to match locations to those borders?

The rest of the solution is simple enough. Once we have the correct time zone, we can convert UTC to the local time and we're done.

Logic that does this should be encapsulated into something that can be easily integrated and reused. Something like a REST API or a local library.

## Just An Exercise

I admit, this appears to have been solved already, but I thought it was a fun exercise. A reminder that we always have to think about time.

Here are some of the resources I found while trying to better understand time zones:

[Olson Time Zones](https://github.com/david-dick/time-zone-olson/blob/master/lib/Time/Zone/Olson.pm)
[Windows Time Zones](https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplemental/windowsZones.xml)
[TimeZoneDB](https://timezonedb.com/references/get-time-zone)
[The radical plan to destroy time zones](https://www.washingtonpost.com/news/worldviews/wp/2016/02/12/the-radical-plan-to-destroy-time-zones-2/)
[What would happen if we abolished time zones altogether?](https://www.wired.co.uk/article/universal-time-zones)
[The hazards of living on the right side of a time zone border](https://theconversation.com/the-hazards-of-living-on-the-right-side-of-a-time-zone-border-116630)
[Why we should be watching the sun, not the clock](https://www.theguardian.com/news/2019/jan/11/watching-the-sun-not-the-clock-sleep-body-clocks-daylight-saving-time)