Turnerj This sentence is False.

The troubles of dealing with Time Zones

Apr 3, 2019

You are an experienced developer who works on a Calendar application, allowing users to add events to their calendar including time and location. A new JIRA issue comes in for you to let users know when there is X amount of time before the event starts. To do this accurately with events potentially being in different regions, you need to think about time zones.

You being the experienced developer you know there has to be a list of time zones by country, all you need is that and calculate the difference between the timezones. When you find that list, you realise it is a bit more complicated than that with a number of countries having 2 or more time zones but no sweat, you have the location information of the event and the time zone the current user is in. You find the more detailed list of time zones and continue on your development journey.

Time zones are typically in 30-minute increments for most countries with the exception of Nepal which has been at offset +05:45 since 1986. Not a problem though, you wouldn't have constrained your system to only hold the data in 30 minute increments - you probably have it being able to support individual minute increments.

You might recall that weird thing that happens twice a year which throws the time back or forward an hour depending on the time of year and hemisphere you're in. That starts to complicate things because now you need to have data on all the countries that follow daylight savings time as well as which direction they go at different points in the year. Did I mention that DST doesn't occur on the same day for everyone?

Hopefully you have realised by now that typing this data into your code or database would take way too long so you're looking up something you can import into your code, you know, if the data ever changes. You find that the Internet Assigned Numbers Authority (IANA) has such a database that you can download. Brilliant thing with this is that it contains DST information too! It seems like your luck has turned and this will still be easy.

Unfortunately you also realise that this database was modified very recently and has an "Announcement" mailing list, that doesn't bode well for a once-off import. No problem though, that is a CRON job calling an importer script in the scheme of things.

You're gonna call it here and say this is good enough. You don't want to worry about political time zone issues, you don't need to worry about historic time zone issues and you definitely don't need to worry about interplanetary time zone issues. You tidy up the rest of your code, resolve the JIRA issue and go on your merry way.

At least your project wasn't needing to calculate the seconds between two points in time, dependent on time zone...

This post is inspired by a fantastic Computerphile video about time zones by Tom Scott. His example goes into some of the more nitty gritty issues like the problems with historic times or leap seconds and I highly recommend you watch it if this article was remotely interesting.