Monday 10 September 2007

Daylight Saving 3: When 'summer' moves

In my part of the world we've hardly had anything resembling a summer... I'd love to know where ours got moved to.

Seriously though... in my previous post I showed how Outlook appointments appear to move when people in different regions 'do Daylight Saving Time (DST) differently. Now we get onto the really fun stuff... when legislature keeps us on our toes by moving DST about.

In 2005, the US Government passed a bill to make DST last longer starting from spring 2007. Various other countries followed suit, and in total 33 time zones changed. Software vendors had to issue patches to all their systems that were DST-aware, Microsoft included. Patches for Windows were released to cope with the change so everyone's system clock should automatically update on the correct weekend.

Because of what we already know about how Outlook stores appointments, this caused meetings to appear to move about. An appointment would have been affected if all the following were true:

  • The appointment was scheduled from one of the affected time zones (i.e. one whose DST rules changed)
  • The appointment was created on a machine with the unpatched version of the time zone information (i.e. one where the meeting was created before the Windows Updates were applied or possibly before they existed)
  • The meeting occurred in one of the 'delta' periods, i.e. the dates between when the clocks would change under the old and new rules (so the spring delta ran from the second Sunday in March to the first Sunday in April)

Here's an example of how an appointment would appear to move just by applying the Windows DST patch to a user's machine:

Appointment time is stored in UTC when the appointment is first created, i.e. before the update was applied to the user's machine:

Appointment time is displayed in Local Time, calculated at the time it is viewed. So this is how it will appear after the update is applied to the user's machine:

Local time in NY

13:00

UTC

18:00

Adjust for Daylight Saving

0:00

Adjust for Daylight Saving

+1:00

Adjust for GMT-5 time zone

+5:00

Adjust for GMT+5.5 time zone

-5:00

UTC

18:00

Local time in NY

14:00

*according to unpatched settings, 15th March is not within Daylight Saving Time

*according to patched settings, 15th March is within Daylight Saving Time

(If those tables don't make any sense, check out this post for an explanation.)

Microsoft released some 'rebasing' tools to help users 'fix' the appointments that appeared to have moved. These were mostly sufficient for the average home user, but for large organizations they had the following drawbacks:

  • The tool could only reliably tell if a recurring appointment had the incorrect DST information and needed fixing. (This is because single-instance appointments don't store time zone data at all.)
  • The user-side tool wasn't easy to automate because of the risk of 'fixing' a single-instance appointment that was already correct.
  • The first iteration of the server-side tool aimed at network administrators was slow, unstable, and required constant monitoring. For an environment of more than a few thousand users it just wasn't a realistic prospect.
  • The next iteration of the server-side tool was released very late - only about a week before the first delta period began, if I recall correctly. Many network administrators felt there wasn't sufficient time to test it, and in any case had already been forced to make alternative arrangements for their users.

Which left a lot of folks looking after large enterprise environments in a bit of a mess.

The organization I was working with at the time has a huge number of users, many of whom collaborate with colleagues across continents on a daily basis. These people are very dependent on their Outlook calendars and take it very personally if someone messes around with their data. Stability was their highest priority, so with the timescales involved we decided the safest thing we could do was provide recommendations to our users of how they could manually fix their own appointments. Our IT support teams out at the sharp end were armed with the client-side rebasing tools to use for coordinators and other people who schedule a massive amount of appointments. We decided it was best for those folks to have some personal help to be on the safe side. Maybe we were too cautious, who knows... without splitting the organisation in two and trying a different approach on the rest of them, it's impossible to say.

Next time I'll share some assorted DST facts that didn't make it into the first three posts.

No comments:

Post a Comment

Creative Commons License This work by TechieBird is licensed under a Creative Commons Attribution-No Derivative Works 2.0 UK: England & Wales License.