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):
- The same absolute (for lack of a better word) time.
- The time in a given time zone, shifting when DST goes on/off (including double DST which occurs in some regions).
- 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.”