Got the time

One of my personal pet peeves is time, how it works and why it seems so hard to get right. There are many aspects to time, both when it comes to programming but also in general. I will only touch on a few of them here and focus on the abomination that is time zones.

General perception

We all have a basic understanding of time and how it works. In school we are taught how to read the clock. a few years later, time zones are introduced. If you are lucky enough you will get to explore how time works in special and general relativity and further more how it relates to entropy. However, I would argue that most people get stuck with a vague understanding of time zones and never moves far beyond that, which is understandable. While the basic idea of time zones is simple the implementation of them is far from simple.

Some History

  • In the beginning no one cared about the time of day.
  • Then we created cities and each one had their own time in order to coordinate time within the city.
  • Then we created railroads and railroad companies introduces time zones to coordinate time between cities.
  • Then we created the phone, airplanes, internet and nothing was done to coordinate time between the now connected parts of the world.

Daylight saving time, which is the concept of switching time zone, was introduced during WW2 to save fuel. After the war the concept remained for no apparent reason.

Some industries seems to have taken the coordination of time on a global level to heart and on their own moved away from using time zones all together. An example of this is the aviation industry which always references time in UTC+00 whenever they communicate.

Communication

Over the years I have had a quite a few problems where time zones comes into play. In a more global environment coordination between vastly different areas is becoming more frequent and messy. I think anyone trying to book a meeting across 3 or more time zones has experienced this.


In May I get the following email

VPS provider:
… during the time window 22:00 - 23:00 CET we will be restarting your nodes to perform upgrades in regards to the Meltdown and Spectre vulnerability …
Me:
… What do you mean? At the moment most of Europe is in CEST (Central European Summer Time), no one in the world is adhering to CET at the moment. Are you referring to UTC+01 or UTC+02 ? …

Turns out they thought CET switch the UTC offset twice a year, it does not.


I was implementing code to send data to a third party in February.

Third party:
The timestamp shall be formatted in UTC+02
Me:
Seems strange, but no problem…
Third party:
Why are you sending all the data with a time offset by 1 hour?
Me:
I assume that you don’t mean UTC+02, as specified, but rather formatted in the local time of Europe/Stockholm? and we are at UTC+01 at the moment

Implementation

When it comes to coding there are quite a few aspects to take into consideration. Both on the UI side of things and how your users relate to time and time zones, as well as how you transmit, process and persist time stamps,

UI

Lets begin by asserting that the only reasonable way of displaying time stamps is ISO8601. Every other way is just a bad idea. So the easiest way to display a timestamp with little room factual confusion would probably be something like
2006-01-02 15:04:05Z
This leave little room for confusion in terms of what it means, but since most of us does not live in a UTC+00 time zone it is hard to relate to.

Forcing people to do time zone calculations in their head is not a good option. So the next best thing might be to look at the browsers internal offset and use that to display the time in a clear manner
2006-01-02 16:04:05 UTC+01
So the good thing here is that we can relate to the time as it is our local one.

Due to daylight saving time we run into problems here as well. Eg. We are in June and want to display the two times pre and post daylight saving time and use the current local offset.
2006-01-02 17:04:05 UTC+02
2006-06-02 17:04:05 UTC+02
The examples above indicate the same time of day in relation to UTC+00 but two different local time of day. This becomes confusing since most people view the time in relative terms, when they get out of bed and so on, and probably just ignore the offset indicated. The problem is then further complicated when we look at a longer time scale. Historically, regions have moved time zones, moved in and out of daylight saving time, skipped days and so on.

To display time in terms that a user can relate to we really want to display it in relative terms for the location of that user. This is however easier said than done, eg. I have not found any reliable way to figure out the location setting on the computer from the browser. Meaning that the offset UTC+02 might mean Sweden, Zambia or South Africa which then have different schemes for switching time zones during the year. What we opt to do is to guess the location and then give the user an option to select the location eg. Europe/Stockholm. We then usually display the time relevant to that location without any offset prefixes
2006-01-02 18:04:05
2006-06-02 17:04:05
eg. mfn.se

Transmission and Persistence

I won’t go too deep into this. But my suggestion is to select one format and adhere to that everywhere. For timestamps always use unix time version, or a text time format that cannot be misinterpreted, that includes the time zone. Meaning that the unix time will always be assumed to be UTC+00 but any other string representation without a time zone portion might be interpreted as UTC+00 or the local time, by you, a colleague or a library that you use.

During the years I have encountered quite a few libraries across different programing languages that handle time, but few as simple, clear and power full as the one provided by the golang standard library. It is built around three concepts, Time, Duration and Location where Time is a timestamp and Duration is always nanosecounds. More importantly, it does not have construct such as Date and Time separated entities nor derivatives of durations such as seconds. Simply put there is no relative aspects about it, time is absolute. This cannot be said of many other libraries.

Food for thought

The EU recently decided that all member states will cease their use daylight saving time. I see this as a step in the right direction, daylight saving time is a source for huge costs to society in general and really provide no significant benefit. However, when daylight saving time is dropped each member state get to choose which time zone they want to be in. We can therefore expect that the union will have 1-3 more time zones once implemented.

Making business easier between states is one of the main goals of the union, and yet they probably made it harder by adding more time zones. A better option would have been to move all states into UTC+00 and then adjust business hours accordingly. There is no law of nature that a work day has to start at 09 and end at 17.


Author:
Rasmus Holm, CTO/Developer