Did somebody say time zones were intuitive?
by Michael S. Kaplan, published on 2006/05/24 00:01 -07:00, original URI: http://blogs.msdn.com/michkap/archive/2006/05/24/605569.aspx
One of the problems about time zones (and believe me, there are many problems with time zones!) is that sometimes it is hard to define what is meant by them.
For example, I am currently sitting in my apartment in Redmond, WA, USA. I am in a time zone that is named Pacific Daylight Time (and which, when DST a.k.a. Daylight Savings Time is not happening) is named Pacific Standard Time.
Many (perhaps most!) people think of this particular time zone as being -08:00 year round, although technically the differenence from UTC (Coordinated Univeral Time) which has no DST changes, is actually seven hours different for part of the year.
Now obviously this makes a string like
Tue, 23 May 2006 14:20:24 -0800
passed to DateTime.Parse a little bit ambiguous, doesn't it? What will it return?
Developer David Zearing of Microsoft noted this issue, when he saw that
DateTime.Parse("Tue, 23 May 2006 14:20:24 -0800").ToString()
is returning "5/23/2006 3:20:24 PM" rather than "5/23/2006 2:20:24 PM".
Now one could argue that keeping the names the same is a good strategy, but the lines are a bit muddled when you have a name that is suggesting a mathematical relationship which you cannot actually use mathematically without first determining the time zone rules in question. A determination that is potentially impossible since two time zones could have the same offset from GMT but different dates for when their DST values kick in (like if Canada decided to not match the upcoming US changes to DST).
This problem also does happen now between Israel and South Africa and Egypt and FLE and GTB and Eastern Europe -- all of which are (GMT+02:00) but many of which are subject to very different rules regarding daylight savings time.
Therefore, the simple name is not enough to give the information in all cases.
Did somebody say time zones were intuitive? Were they high at the time?
This post brought to you by "±" (U+00b1, a.k.a. PLUS-MINUS SIGN)
# gabr on Wednesday, May 24, 2006 4:24 AM:
Time zones are simple. Daylight Savings Time is the problem - it should be abolished all over the earths.
(die DST die die die)
A life without time zones would be even more confusing ...
# Nick Lamb on Wednesday, May 24, 2006 5:28 AM:
"like if Canada decided to not match the upcoming US changes to DST"
Is there any good reason why Windows doesn't follow the Unix timezone naming practices (ie America/Los Angeles, America/Vancouver and America/Tijuana etc.), which would make this sort of thing (which is all too common) easier to deal with, for software developers, system administrators and users ?
Maybe something for your "What's next?" queue.
# Phylyp on Wednesday, May 24, 2006 6:10 AM:
The earth is flat and there are no timezones.
Oh, how I wish that were the truth!
# Michael S. Kaplan on Wednesday, May 24, 2006 7:50 AM:
Hi Nick --
That is how things are currently handled across the masny different GMT +02:00 time zones, all of the definitions of which list cities -- and as I pointed out, they do not solve the problem I pointed out.
But adding artificial time zones before such differences actually exist is not really a good solution here. Since neither method actually solves the problem (and Unix is just as broken here, mainly due to the flaws of the model).
# Nick Lamb on Wednesday, May 24, 2006 10:49 AM:
"all of the definitions of which list cities"
But you have it the wrong way up, you've got this list of timezones, and they are described to the user as so-and-such UTC offset, and then a series of place names. It's the same mistake as we saw in several previous dialogs on Sorting It All Out.
"and Unix is just as broken here"
In Unix, the users get new tzdata packages as updates which handle the (hypothetical) changes to US vs Canadian timezones, and carry on as before. In Windows every single affected machine or account must be (manually?) reconfigured. Well, we know that won't happen, so actually millions of machines would just have the wrong time.
If you're talking about the offset date-time format, that isn't broken in Unix because Unix software understands the difference between a UTC offset and a timezone. Trying to treat the offsets as if they were timezone information will screw you up, as you amply demonstrated.
This is a bug, like the UI language stuff a few posts back. Pretending everyone else is wrong, or that people just don't understand the problem might persuade a few naive readers on this little blog but it only puts off the work of actually fixing the problem. Let us know how you get on with that.
# Mihai on Wednesday, May 24, 2006 12:42 PM:
For the problem presented Unix is as bad as Windows and as bad as anything else.
The time expressed as "Tue, 23 May 2006 14:20:24 -0800" gives no hint where I am.
I am 8 hours off GMT, but no clue what latitude, so I don't know if I am in Canada, U.S.A., Mexico or somewhere in Pacific, southern emisphere.
# Michael S. Kaplan on Wednesday, May 24, 2006 1:01 PM:
Hi Mihai,
It is a very important thing to Nick to be able to take any issue I raise in the blog, change the topic, and explain how Microsoft or I or both are wrong.
This is a special service I provide to Nick, and I don't mind doing it at all.
:-)
# Ben Cooke on Wednesday, May 24, 2006 2:15 PM:
If I know a given time is being given as eight hours behind UTC, most of the time I don't care which timezone it was recorded in. I'm in the UK (currently on British Summer Time, UTC+1) but there's nothing to stop me saying that the time is currently "21:14 +0300" rather than "19:14 +0100".
The problem of course comes when you want to figure out what someone's local time was at that point, but I'd argue that the best way to do that is just to ask that someone. A few applications I use deal with this by logging the UTC time and my local time, so you can say "Ben did that at 19:12 his time, which was 16:12 my time and 15:12 UTC", which is all you really need in most cases, right?
# Maurits on Wednesday, May 24, 2006 2:38 PM:
To me, this string implies Alaska.
Tue, 23 May 2006 14:20:24 -0800
If you're in Washington, Oregon, Nevada, or California, you should have gotten:
Tue, 23 May 2006 14:20:24 -0700
because all of those states observe DST in May.
Ambiguity arises for the -0700 string, though, because you could equally well be in the portion of Arizona that does not observe DST.
But the function of the -hhhh syntax is not to specify where you are... it is to specify what the current time zone offset is. A little math and you can convert it to any other time zone offset you want.
# Maurits on Wednesday, May 24, 2006 2:46 PM:
Oh, and the -hhhh syntax helps resolve the time-space-continuum holes caused by "spring ahead" and "fall back"....
01:59 -0800
02:00 -0800 ready... SPRING AHEAD:
03:00 -0700 ... same time, different syntax
03:01 -0700
...
01:59 -0700
02:00 -0700
02:01 -0700
...
02:59 -0700
03:00 -0700 ready... FALL BACK
02:00 -0800 ... same time, different syntax
02:01 -0800 deja vu...
...
02:59 -0800
03:00 -0800
03:01 -0800
# Nick Lamb on Wednesday, May 24, 2006 3:13 PM:
"explain how Microsoft or I or both are wrong"
And if only Michael would listen we might make some progress...
For example, imagine if Michael had filed a bug when I first pointed out the problem with paragraph level reading order... by now it might be fixed in the source tree, and Vista users would soon be praising the (to them) anonymous guy who made it happen.
Of course, I'm not here because of people running Windows, or rather, I am here because today the same people are using the same data, and even the same applications, on non-Windows systems. I'm telling my neighbour his barn is on fire, not just because it seems a shame for his barn to burn down - but also because my barn is next door.
Which brings us right back round to where we started. Timezones are timezones, UTC offsets are just offsets. Everywhere that Microsoft (or anyone else for that matter) gets this wrong in data on disk or on the wire, is a place where everyone else has to try to figure out a workaround, or else the user gets the wrong time and they don't know who to blame.
# Michael S. Kaplan on Wednesday, May 24, 2006 5:07 PM:
Nick,
I do listen. But you have an agenda that involves changing the topic to making it your own.
That is great. But at some point you should put it up on your own blog. Eventually I will delete the offtopic comments.
As for paragraph level reading order, I understand you and DISAGREE with you. You may need to get over your bitterness on this point that you simply refuse to let go.
SUMMARY: It is possible to disagree with Nick Lamb. It is even possible that in those cases, Nick Lamb might be wrong....
# Dennis E. Hamilton on Wednesday, May 24, 2006 6:03 PM:
I love calendar and date-time and timezone and time-standard stuff. It is a great way to demonstrate that there is no way to "get it right" in software when any assumption about what is intended is incorrect at least 1/3 of the time.
I stopped reading the comments when my screan started to darken and melt around the edges and I could smell ozone, but I thought there was an important point.
I always thought giving the time in GMT (e.g., 23:51Z which it is as I type this) was not a reference to a location but to a universal time standard that is consistent no matter where you are located on the planet and what the local time might be there.
I also confess that it slips my mind that time zones are thought of as geographical (which the picture in my Day-Timer and in some phone books reminds me of). I actually find the city associations to be weird, because I am not in that city (whether Tijuana or one of the other ones that are apparently in the same time zone as I and are the limited choices I am offered).
So I always think of 16:54 -0700 as a time offset for local time from UTC (also known as PDT where I happen to be at the moment). As long as I am always using ISO-mumble times as times related to UTC, everything seems to work. I gather that the concept is overloaded if we want it to give us something geographical too (though generally spanning both hemispheres and having very peculiar properties near the poles, but what the hey). They don't exactly follow longitudinal lines either.
Sticking with the notion of UTC offset has worked fine with me. I can write it down without thinking and someone else who cares can figure out what time it was in GMT or even in their local time (given an accurate [local-time] date of course).
I thought this was all pretty easy until I started adjusting my computer clock when traveling and had Outlook be completely confused, even when I set two time "zones" on the calendar. Whatever one size fits all is applied there, it is a site that never fits me and now I have a bunch of all recuring all-day appointments that now start at 1am and continue into 1am the next day.
(Sigh).
# Dennis E. Hamilton on Wednesday, May 24, 2006 6:19 PM:
PS: I just signed up for two web casts. I am told that the one tomorrow is at "2 pm Pacific Time (US & Canada)." Downloading the appointment into outlook, it is nicely placed for one hour starting at 14:00 PLT on my calendar. My calendar has another column labeled GMT and it says 21:00. I did not do any adjustments to Outlook in the vicinity of April 2.
Now, the web site that has these little webcast announcements actually gives the time as "Event Time:
2:00 PM Pacific, USA & Canada (DST) = GMT - 08:00" and it does that year round. That was very confusing until I learned to ignore it and trust that the 2:00 PM is Pacific Local Time (PDT this time of year) and I can figure out from that how to log in at the proper time from the time zone I am in at the moment. The downloaded calendar appointment got it right, and that's good enough for me.
And when I travel, I never, never, ever change the local time on my laptop. It just screws up too many things, including FTP transfers of presumably-only-changed files with a server that is not traveling (and whose time offset, like as not, is set incorrectly anyhow).
Fascinating, simply fascinating.
# Tyler on Thursday, May 25, 2006 2:25 PM:
Simple solution: no daylight savings time.
Simpler solution: no time zones.
I hear that China has only 1 time zone, and they seem to get along just fine despite having room for 5.
# Peter Cooper Jr. on Thursday, May 25, 2006 5:17 PM:
The thing with Outlook appointments and the like, is that some appointments (like Birthdays and regular meetings) are really at a particular local day & time no matter whether I'm in daylight time or not, and for things like Birthdays the actual time really does move with me when I change time zones. But for some things, like a global webcast, or a company meeting amongst people in different time zones, it has one absolute time that really ought to stay in the same actual time as I change time zones. (Although if it's recurring, then it may change if the majority of the company goes on daylight time.)
So it seems like when creating an appointment the user ought to be able to describe how it should work when changing time zones, although that could never really happen since users probably don't know the answer.
# Maurits on Thursday, May 25, 2006 5:38 PM:
Simplest solution: no clocks ;)
# Ben Cooke on Friday, May 26, 2006 6:46 AM:
Peter,
You've named one good case that is difficult to solve. It's impossible for me to say "remind me at 9:00 Peter's time every day" because I have no idea where you are and what timezone you're in. Even if I did know that, the software I'm using would need knowledge of the daylight savings switchover times for every single timezone.
And that's ignoring those people who insist on completely ignoring daylight savings time. They do exist. I used to know a guy who would leave his watch on standard time all year and would do everything by his wallclock time. As far as he was concerned, he just had to go to work an hour earlier for half the year; in other words, "the rest of the world is wrong." I like that attitude, but it seems like far too much effort for me so I just go with the flow. I do, however, have one clock here in my home office that is set to GMT rather than BST, since it shaves a few milliseconds off my own mental UTC offset calculations when I see timestamps!
Please consider a
donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.
referenced by
go to newer or older post, or back to index or month or day