What Time Do You Really Mean?

When you say 7:00 – what do you mean? For human beings who deal well with ambiguity, this can be confusing when they are in different time zones. For a computer it becomes even more complex. I wrote an article about this for developers figuring 20 would read it and 3 would find it useful. What happened was close to 10,000 views/day for the first couple of days (and it’s still going strong). By this measure, I figure that non-programmers might find this interesting.

So here it is written for the user’s point of view. How to handle time is one of those tricky issues where it is all too easy to get it wrong. So let's dive in. (Note: We learned these lessons when implementing the scheduling system in our reporting software system.)

So let's start with the key question – what do we mean by time? When a user says they want something to run at 7:00 am, what do they mean? In most cases they mean 7:00 am where they are located – but not always. In some cases, to accurately compare say web server statistics, they want each "day" to end at the same time, unadjusted for DST (Daylight Savings Time). At the other end, someone who takes medicine at certain times of the day and has that set in their calendar, will want that to always be on local time so a 3:00pm event is not 3:00am when they have travelled half way around the world.

So we have three main use cases here (there are some others, but they can generally be handled by the following):

1. The same absolute (for lack of a better word) time.
2. The time in a given time zone, shifting when DST goes on/off (including double DST which occurs in some regions).
3. The local time.

And let’s not forget to add one little corner case (this is the kind of thing that makes writing bug free software such a challenge). Let’s say you set your daily backup to run at 2:30 am when no one is on the system. Well once a year it runs twice and one day of the year it does not run. When you go from daylight to standard time 2:00 – 3:00am occurs twice. And when you go from standard to daylight, 2:00 – 3:00 am never occurs.

So on to the above cases. The first is trivial to handle – you set it as UTC (Coordinated Universal Time – the ordering of the letters are a compromise with the French when this was set). By doing this every day of the year will have 24 hours. (Interesting note, UTC only matches the time in Greenwich during standard time. When it is DST there, Greenwich and UTC are not identical.)

The second requires storing a time and a time zone. However, the time zone is the geographical zone, not the present offset (offset is the difference with UTC). In other words, you store "Mountain Time," not "Mountain Standard Time" or "Mountain Daylight Savings Time." So 7:00 am in "Mountain Time" will be 7:00 am in Colorado regardless of the time of year.

The third is similar to the second in that it has a time zone called "Local Time." However, it requires knowing what time zone a user is in in order to determine when it occurs.

The above requires software to stay on top of the DST rules. Argentina once set a new start for Daylight Savings Time with 8 days notice. Most programs pull this information from the operating system, but it requires that people do run service packs when required. And that programs recalculate absolute time when the rules change.

What do you need to do?

In Microsoft Outlook, when scheduling an event, it stores the local timezone. You can override this by clicking on the “Time Zones” button. You will note that it does not list standard or daylight times but the zone name – so setting an event to 7:00 am Mountain time will be at 7:00 am during both standard and daylight savings time. It also includes the choice of UTC. So well handled by Outlook – just set the time.

Now take a look at the iPhone. Apparently the iPhone has no idea that time zones exist. Everything is local time, except when it synchronizes with an Exchange server where it then assumes everything is in the server’s time zone. Very bizarre that Apple gets this so wrong.

Most websites that give you a login let you set your timezone. Unfortunately you don’t want to go change that everywhere when you travel so your best bet is to just live with the sites giving you the time at home rather than where you are. If browsers eventually pass their local timezone to the website (see below), then this will be handled automatically – which will be a nice improvement.

Finally, when you travel, always change the timezone on your laptop. Even for programs that are timezome oblivious, it’s almost always better to have timestamps synchronized to the local time. But if you fly from say Japan to Seattle, where you arrive before you left, there are some programs that get very confused that time moved backwards.

Browser pain

Ok, so with all of the above why does a system have to ask you for your time zone when you access it with a browser? Because, while a browser does pass its locale (language & country), it does not pass the time zone. There are tricks that can be done to guess, but they don’t work well for the U.S. or other wide countries like Canada & Russia. This will likely be added to browsers in the future now that people constantly hit numerous websites while travelling.

Was this of interest?

You made it to the end of the article! I have no idea if posts like this are of interest and comments are the only way to judge. So if you would like to see an occasional post like this from me, please comment even if it’s just the words “more please.”