« Programmatically Change Save Window State Settings | Main| My Domino DST Fix Utility for Custom Applications »

Domino DST for Dummies - Custom Application Edition

QuickImage Category   

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)


1 - Hi Doug,

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 .Emoticon .

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.

Your Host

Kevin Pettitt View Kevin Pettitt's profile on LinkedIn

Tools I Use

Idea Jam

Subscribe to This Blog

 Full Posts  Comments

netvibes Add to Netvibes


Hosted by



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.

© 2005-2019 Kevin Pettitt - all rights reserved as listed below.

Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution / NonCommercial / ShareAlike