What Time Is It? Challenges of Multiple Time Zone Support

What time is it?

It’s a simple question, isn’t it? You just need to take a quick look at the clock (or any device that shows you the time) and you have the answer. Or do you?
Let’s take a quick look at this picture.

Let’s also assume that it’s currently dark outside and try to answer our question from the title. What time is it? One person will say that it’s 23:55, while someone else will say that it’s 11:55 PM. Both answers are correct, but people in different parts of the world might find one or the other confusing. For example, the British are mostly used to the 12 hours clock, while the Polish tend to use the 24 hours clock more often. As you can see, our initial question has gotten a minor degree of difficulty and that’s only the tip of the iceberg.

I hope you are sitting comfortably, with seatbelts fastened. That’s because we are about to take off in order to go deeper.

Read also: How to deal with a time zone difference in outsourced projects

Let’s play at 1:00 PM!

I used to be a part of an international reddit community in which we organized games. Those games were always set to start at a certain time. Depending on where a player came from, this would mean a different hour for him or her. This is where time zones and their conversions came into play. Needless to say, they were a major source of confusion.

Every game had its time given in UTC (Universal Time Coordinated), which is the primary time standard in the world. Everyone had to convert from UTC to their own time in order to join the game at the right time. Additionally, some people had to convert from the 24 hours clock to the 12 hours clock, because that’s what they’re used to.

In order to make things simple, let’s make one thing clear. Every time zone can be defined as an offset from UTC (in hours, sometimes not full hours). Let’s look at some popular ones.

Central European Time (CET) = UTC + 1

GMT (Greenwich Mean Time) = UTC + 0

Eastern Standard Time (EST) = UTC – 5

Pacific Standard Time (PST) = UTC – 8

Let’s say that the game post said that the game would start at 13:00 UTC. This means that someone living in Warsaw would need to join at 14:00 (2:00 PM) and someone living in Los Angeles at 5:00 (5:00 AM). That’s assuming that those areas are currently using those time zones, which is not entirely obvious.

Let’s play at 1:00 PM!

Whether daylight savings are a needed thing is a discussion for another time. As of now, we just have to accept that they take place in many parts of the world. In order to talk about them, we need to clear a common misconception. Let’s say you live in New York and your time zone is EST. What happens when you enter daylight savings? Does EST go from UTC – 5 to UTC – 4? The answer is NO! Thinking this way leads to more confusion. Let’s make one thing clear: DAYLIGHT SAVINGS DON’T CAUSE SPECIFIC TIME ZONES TO CHANGE THEIR OFFSET FROM UTC! What actually happens is that you switch your time zone from one to another. In the case of EST (UTC – 5), you switch to Eastern Daylight Time (EDT, UTC – 4) for the duration of daylight savings. Remember, though, that not every area undergoes this change. For example, Jamaica uses EST all year long. Russia opted out of daylight savings a few years back. Let’s look at the same time zones and their daylight savings equivalents in specific countries.

Not every place on Earth switches into or out of daylight savings on the same day. In 2018, USA entered daylight savings on March 11th, while European countries will do that on March 25th. This means that you can’t just count on the fact that New York is 6 hours behind Berlin – there are a few weeks in every year when this is not true.

Multiple time zone support

During my time at Neoteric, I worked on a piece of software called Appoint.ly. It’s a simple scheduling application. Because of that, I find the following joke very relatable.

Elon Musk: I’m putting people on Mars!

Developers: Fantastic, more time zones to support.

In this application, users (called “calendar owners”) can send other people (called “participants”) links in which they can choose a time slot that suits them best for a meeting. Before that, calendar owners have to define appointment types. In those appointment types, they set their availability. For example: Mondays and Thursdays from 8 AM to 4 PM. Calendar owners and participants can live in different parts of the world, so this needed to be taken into account when displaying available timezones.

If you are a developer, I want you to consider this: how do we store the availability for an appointment type? In most cases, storing the time in UTC and letting the browser translate it into a user’s timezone would be enough. Not in this case.

I live in Poland, we use the CET (UTC + 1) time zone during winter. Let’s say I set my availability to Mondays from 8:00 to 16:00 and that’s when I’m available all year long. If I stored this in UTC, it would be stored as 7:00 to 15:00. This would work perfectly well until the switch to daylight savings would occur. At this point, I’d switch to the CEST (UTC + 2) time zone and my availability would shift to 9:00 – 17:00. This means, that local time needs to be stored, as well as the UTC time – it’s still needed for conversions between calendar owner’s and participant’s time zone.

I mentioned before, that every time zone can be represented as an offset from UTC. It’s also like that in the POSIX standard, but… the other way around. EST is 5 hours behind UTC (UTC – 5), but in POSIX it’s represented as UTC + 5. It was a source of major confusion during the development, because my coworkers never quite knew what I meant, when I said ‘EST is UTC – 5’.

Maybe the day will come when we’ll all just use the universal time.This would mean, that in different parts of the world the day would take place at completely different hours, but at the same time, we would get rid of many problems. It might also never happen due to cultural ties to specific hours. The British and their tea at 5 o’clock is a good example here. As of now though we have to work with time zones, whether we like it or not.