DST 2007: Why we needed to rebase appointments

I thought I wouldn't need to post about DST 2007 issues after it kicked in on Sunday March 11th this year, but apparently that doesn't seem to be the case.

In a previous post (that I've referred to a number of times now) titled "DST 2007: Understanding what needs to be done and how to do it", I explained how computers keep time and how Outlook creates appointments.

While taking a break from the MVP Summit schedule earlier last week, I came across this eWeek article by Peter Galli titled "Time Change Brings 'Nightmare' Issues with Outlook, Calendars". The article quotes Robert Rosen, CIO of the National Institutes of Health's National Institute of Arthritis and Musculoskeletal and Skin Diseases. "Microsoft in particular requires operating system patches and then Outlook calendar modifications. That makes no sense. If they were storing in Coordinated Universal Time, the operating system patch should have fixed the calendars automatically".

After some reflection, I've gone from that line of thought, to a more logical explanation.

Rosen's line of thought, and mine to some extent when this thing started - if Outlook stores appointments in UTC, which is a universal time that shouldn't change, appointments should always be rendered at the correct time by merely telling the OS when DST starts and ends.

Here's why that line of though isn't correct: users don't book meetings using UTC. They do using their local time - let's say 4:30 PM Pacific time.

When saving the appointment, Outlook uses the time zone in effect on the day of the meeting to calculate the UTC Start Time and End Time. For the 4:30 PM appointment on March 12th, 2007, using the time zone in effect according to the older DST schedule, which would still be Pacific Standard Time or UTC -8:00, the UTC Stard and End times would be 12:30 - 1:00 AM on March 13th, 2007. Here's what the appointment looks like originally.
(Note: A recurring meeting is shown in the screenshot, with the CommonStart and CommonEnd properties so they can be captured on the same screen along with the time zone property - Bharat)


The operating system (OS) is told about this new DST schedule (by applying KB 931836 time zone update).

Now, the appointment Start and End time, though saved in UTC, end up being wrong! UTC 12:30 -1:00 AM on March 13th, 2007, turns out to be 5:30 - 6:00 PM Pacific time on March 12th, according to the new DST 2007 schedule.

Thus the need for "rebasing" those appointments occurring in the affected DST period, which actually adjusts the UTC start and end times of those meetings so they get rendered correctly (in local time) by Outlook. Here's what the 4:30 PM appointment on 3/12/2007 looks like after rebasing.


If users scheduled meetings using UTC to start with - a difficult task that would certainly impact the productivity and increase user frustration - meetings would always have a constant UTC time, irrespective of local time. (As a sidenote, this would have its own implications... but I'd rather not go into more details at this point, now that the DST 2007 change is behind us :-).