Domino DST for Dummies - Custom Application Edition

By now most Domino professionals in
North America are aware of the looming Y2Kesque Daylight Saving Time change
fiasco (if you're outside North America, pay attention to this issue anyway
since your Domino environment may still be impacted). Administrators
are of course having the most fun, patching server and client operating
systems, updating Domino Web Access support files, updating all kinds of
java stuff, and then getting IBM's calendar fixup agents ready to run on
user calendar's and the Room & Resource database. Now developers
are now starting to realize they may not be getting off so easily, and
IBM doesn't have any magic fix agents you can use to clean up the mess.
Since I'm now 10 days into this realization myself, I thought I'd
share what I've learned about evaluating the impacts (if any) to custom
Notes applications.

But first a brief word on International
Impacts. Do you have any users, anywhere in the world, whose
machines are set to use a North American Timezone? or Do your internal
users arrange meetings through calendar invites with folks outside the
organization who are based in North American timezones? If you
answer yes to either of these, and any of these users are involved in meetings
or conference calls, etc., you have some MAJOR data cleanup to do if you
want everyone to show up to those meetings at the same time. You
should *immediately* jump on this problem because you've already taken
too long. Start here.

Ok, now, back to you developers. So
you've been asked whether any of your applications will be impacted by
this DST thing, and you're wondering if there's an easier way to figure
out the answer than wading through dozens of technotes. Well, maybe.
The problem can be broken down into two parts: past, and future.

Past Impacts

Do you care that historical dates
from 2006 and earlier that fall in the expanded definition of DST will
be off by an hour?

What is really odd about this whole
affair is that we're also redefining DST for past years. For some
reason the OS patch (at least on Windows), is screwing up historical dates,
when it SHOULD have no impact on previous years. This I believe is
a flaw in the operating system, but oh well. This will throw off
pretty much any date/time field value during the weeks that fall inside
the new definition of DST, which includes fields that track the time of
submission, completion, etc. If you place any importance on the accuracy
of this "archival" time stamp information, you'll need to look
at this in more detail.

Future Impacts

If you have any sort of custom calendar
and scheduling application such as the home grown room reservation system
I'm working on, you'll almost certainly need to do some data cleanup before
March 11th. If you can say "No" to either of the following
questions about a given application, it should be fine as far as future
dates are concerned (as long as your admins get all those OS patches done
in time):

1) Does the application have any
Date-Time fields with *future* values?

If all your date fields are "historical"
(e.g. DateCreated, DateSubmitted, DateClosed), you can't possbily have
any values that fall inside the "fun zones" of March 11 - Apr
1, 2007, etc. In that case move on to the next application.

2) So, you have some future dates, and
yes, some of them fall in the "fun period". Do any of
those date fields include a *time* component that you care about?

By "care about" I mean will
the application do anything bad because this field jumped an hour forward.
For example you may have an ArchiveDate field set 6 months into the
future when a document is created, but not care if the time is 2AM or 3AM.

Other Resources

If you need to get up to speed quickly
on Daylight Saving Time impacts on Domino, Chris Miller has recorded some
great podcasts that cover the issue in a very helpful and understandable
way. Susan Bulloch of IBM is at the forefront of IBM's efforts to
support the Domino community through the DST maze and has some great tips
and information on her blog. Both have a wealth of links to key IBM
technotes and are a great starting point for research.

Next Episode: What do you do
if your applicaiton is impacted by the DST Change? (Hint: Don't panic)

Comments

I actually did mention the impacts on past dates higher up in the post. If that is an issue for anyone, you can do a data cleanup of those old documents. The problem is straightforward but daunting, and its probably best to leave things alone and simply put an asterisk on all future audit reports. Perhaps some footnotes about which dates from previous years "should be treated as off by an hour" would be enough.

Probably the biggest problems with cleaning up all those past documents though is that all of the save dates and signatures will be lost. The latter side effect is certainly more important in terms of auditing than times being off by an hour.

And don't be surprised if Congress decides to go back to the old rules next year, requiring all of us to repeat the exercise. At least then all those pre-2007 times will be correct again . .

And yes, I agree that how the operating system handles dates is fundamentally broken. I mean, given that the whole Gregorian calendar is basically a hack and lacking in any logical structure (months of different lengths, leap years, etc.), why have a single definition of DST that applies to all years? I think Windows and other OSes should be setup such that whatever rules or patterns are overlaid onto the calendar have distinct start and end dates for applicability. This would have enabled all OSes to be patched as soon as the legislation passed, and not just before it took effect. As it is, applying the patch last September would have screwed up DST for last October/November. Stupid.

2 - Just catching up on my blog reading and ran across this post. My response is clearly late, but what the hey...

) Does the application have any Date-Time fields with *future* values?

If all your date fields are "historical" (e.g. DateCreated, DateSubmitted, DateClosed), you can't possbily have any values that fall inside the "fun zones" of March 11 - Apr 1, 2007, etc. In that case move on to the next application.

Not quite true.It seems that all dates ever inside the 'fun zones' get adjusted after the DST patch is applied. If something originally shows as happening at 10 am, after the dst patch, it is automagically moved an hour. All dates in this range back to the beginning of time...Cool! Also way fun if you happen to discover this in an audit where a printed copy of a doc has one time and the Notes record has another - wow, looks like fraud.

Nothing you can do since the problem seems to be tied to the way MS implemented this particular dst patch, just be aware of the issue and be prepared to explain it if asked.

Disclaimer

This site is in no way affiliated, endorsed, sanctioned, supported, nor blessed by Lotus Software nor IBM Corporation, nor any of my past or future clients (although they are welcome to do so). The opinions, theories, facts, etc. presented here are my own and in no way represent any official pronouncement by me on behalf of any other entity.