January 15th, 2007
DST2007 - Part 2
It appears that I've gotten your attention. I've also gotten linked to by Ed, so that drives up traffic a bit and reaches a larger audience. Excellent! So what happens now?
First, you're going to get a game plan together to update all of the operating systems on all of your computers, right? If you don't have it yet, send somebody off to do that while you read this. Today, I'll cover some planning, prep and caveats about the process.
Warning: Do not do any type of time shifting with production computers of any type.
What is time shifting? That's doing the thing you inevitably want to do, which is to shift your Operating System time clock forward to see what happens on March 12, 2007 or April 1, 2007. Doing this will cause untold heartache. Why? Well, when you shift your time forward and open any software that has time/date stamps, things get logged. So for instance if I pretend that it's March 12 and run some tests, Notes or Domino will obligingly stamp my log and anything else it can with the time and date as it understands it from the operating system. When I shift back to real time, Notes and Domino and anything else that runs on a schedule will wait for the 'next' time interval before doing anything. Problem is, the next time interval is now 2 months away, so your software does nothing until then. If you've ever done this - either by accident or by testing back in 1999, you know that its very difficult to make software forget where it's been while time traveling. Mail stops routing, replication stops, etc. So the first rule of testing with time is to set up test systems that you can toss out afterwards. VMWare is especially useful for this purpose. There are other VM products of course, this is just the one I use.
Expect some confusion. There's simply no way around it. Since each PC and server has to be updated, there will be some period of time, whether in minutes, days or weeks when you will coexist with machines having the new definitions of DST and those with the old settings. Servers are more under your control of course, but there can still be a bit of a time issue. When a user has installed an OS patch already, all calendar entries going forward are correct and show up correctly in the views. Chairs of meetings who have not upgraded at the OS level will be sending out notices that will later be 'corrected' to the proper settings by some method. When those corrections are done, you could be double booked.
Listening to colleagues from Australia and Brazil, this isn't the end of the world when it happens, although it is annoying. Policy makers tend to not consider the downstream impact of decisions like this - we'll just make it work. If you communicate with your users about the upcoming change, they'll be better equipped to know what's happening. Which brings me to my next tip.
Communicate with your users. Yes, let them know what's happening. Now. The start and end dates of Daylight Saving Time are changing. There will be changes needed to all automated systems. Some of these changes will be visible to your end users while they are happening, and if you tell them about it, they'll stress less, and probably log fewer calls to your help line. Tell them to stand by for more information later, but do let them know now.
Start Testing. Do not delay - test the deployment of your server and client operating system updates. Determine where money can be lost by the time stamp being 'off', and fix those systems early. Then go on to the other systems like Notes and Domino.
More on those coming up next.
