Ok, so there may be *some* worries here

by Michael S. Kaplan, published on 2006/04/05 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/04/05/568208.aspx

I fell into a trap that is quite common when working on lower level components like NLS, the trap of assuming that just because the lower levels components can handle a problem properly that all of the higher level applications can do so as well.

Obviously if you are a customer using such an application, then this is a distinction without a difference -- failure is failure.

So I would like to apologize for forgetting this rather crucial point for a bit there.

In this particular case, the time zone data is appropriately updated so that all conversions will follow the new behavior for the region.

However, in response to this post, Fil Mackay pointed out one of the problems that can (and has, and does, and will) happen in applications in this comment:

The problem is obvious -- storing everything in UTC time and then displaying in the appropriate local time is almost always a great strategy -- the one exception being that if the time zone definition changes than some appointments will be "moved" inappropriately, as Fil indicated.

The end result -- everything is handled, like I said -- though in a way that is a huge horking pain in the ass.

Both the Outlook team and the Exchange Server team (as well as just about every other Microsoft employee and contractor in the world) are here at Microsoft and have meetings and schedules just like everyone else.

What better way to force one of these teams to create a new utility to help adjust all the appointments to be appropriately moved after this sort of update?

I realize as I write this I am still being glib, but this time it is aimed internally to teams at Microsoft that are most likely and obviously going to blamed anyway once everyone's schedule gets incorrectly shifted.

But that is the sort of glib that I think customers can really get behind, right?

You said in the post: “storing everything in UTC time and then displaying in the appropriate local time is almost always a great strategy”.

I think you are wrong, storing everything in UTC is almost always the wrong strategy.

Having your schedule in UTC format makes sense only for international conference calls, when I schedule an appointment for 3:00pm then it should remain at 3:00pm local time, if day light saving time “kicks in” between the time I scheduled the appointment and the appointment itself then outlook will move it to 2:00pm or 4:00pm (depending if it’s the start or end of DST obviously) .

I don’t know how it is in the US, but here when we schedule a meeting we schedule it in local time, not UTC, and storing the time in UTC will make me an hour late or an hour early.

What I do on all my machines (my home PC and all machines at work) is not to use the Windows DST feature, we disable it and just set the clock – this makes Windows wrong when trying to get the UTC time but it makes Outlook work correctly.

Storing times in UTC is a good strategy when you need to coordinate across time zones, for example international conference calls or airlines schedule but for a daily schedule it’s just plain wrong.

This might be different in the US, I live in a country that is completely inside just one time zone, but this feature of outlook really bugs me twice a year (or more correctly, used to bug me twice a year, until I found the only way to keep Outlook in sync with reality is to lie to the Windows time applet)

At this opportunity, I wanted to share with you a short note about Israel and our timezone (IST/IDT). Microsoft seems to have given up on maintaining automatic daylight saving switching for GMT+02 Jerusalem, due to its frequent changes of policy; Windows 95 was the last version it appeared in. On Linux, one of the universities maintains an up-to-date timezone file which specifies the switching times as they are at various years.

Starting from 2005, the Israeli law for switching to Daylight Saving Time is "on 2:00AM at the last Friday before 2nd of April". On Linux, it's possible to declare multiple years ahead so this complex rule can be precalculated forward for some hundred years (heck, till 2038 :). Is this even possible on NT? If so, will automatic daylight switching return to GMT+02 Jerusalem in Vista? I'm sure many sysadmins would love that.

P.S. Currently there's are registry updates distributed at http://www.lingnu.com/support.html#timezone but they cover only one year at a time.

"Storing everything in UTC is almost always a good strategy" - I strongly agree with that. It's the bestest strategery I know of for things that have happened - past events.
"You created this file at 4am on Monday" shouldn't suddenly remain "You created this file at 4am on Monday" if I move two time zones across.
Storing things as "time + time-zone" is an irrelevant replacement for storing things as UTC. Unless you live in London in the winter, and hibernate through the summer, you are pretty much never going to want UTC to be the "display time" - even using it to schedule international phone calls is only a poor substitute for displaying the time to everyone in their local time zone.
For future events, though, it is considerably harder to predict what would be a good strategy.
When is my birthday? I'd say it's June 6th. Outlook tells me it's from 10pm June 5th to 10pm June 6th. That's dumb, and results from my moving from Texas to Washington a couple of years ago. Same goes for everyone else's birthday, Christmas, etc. There's a set of events that are purely local time.
When am I having my regular 2pm meeting in three years? 2pm. Whether the daylight savings change has been made earlier or later in the year. Again, purely local time.
Well, how about the live broadcast of New Year's celebrations from London? That's going to be just before midnight GMT, no matter where I happen to be living at the time - so that's an appointment that must not be stored in local time.
Then there's the exotic events - say, for instance, the "total eclipse of the sun" - whose time depends on where you are, and might, or might not, be related to the local time zone there.
So, there you have it - past events unequivocally are best stored in UTC, and displayed in whatever format is comfortable for the viewer, usually local time as it was at the time of the occurrence, with the ability to display UTC to confirm duplicate times.
Future events might be best stored as UTC, or might be best stored as "local time", but only the user will know in most cases.

What I was trying to say is that people’s schedule usually makes sense only in local time, if I have a team meeting every week at 2pm then it should remain 2pm local time even if daylight savings time just began (as Alun just said).

Are there more people using outlook to schedule cross-time-zone appointments then people who get mad when all their appointments move an hour two time a year?

I really like Alun’s example of birthdays moving around, that’s just funny.

I’m talking about Outlook here, not file times.