Thomas J McArthur 22.Feb.07 12:36 PM a Web browser Daylight Saving TimeAll ReleasesAll Platforms
I have tested the DST code that was provided by Lotus/IBM, and my test shows that the code makes the problem worse.
Test environment:
* I used both a WinXP client and a Win2K client for the testing - both clients have been updated with the DST fix (the Win2K client was fixed with the TZEdit tool)
* The server is 6.5.5 FP1 on an AS400/iSeries that has had the OS updated
* I made a new copy of my R6 mailbox (which has entries for the new 3-week DST period)
* I ran the 4.0.2.3 version of the "admin" update code over that test mailbox
* I have a dentist appt at 10:30 during that 3-week period - obviously, that should still happen at 10:30, regardless of Eastern Daylight Time or Eastern Standard Time
* After fixing the test mailbox, I viewed the fixed entries using my Win2K machine, and with a WinXP machine that has had the date advanced to Monday, March 12th
Symptoms:
* When I view my mailbox with my Win2K client, the entry correctly appears at 10:30
* When I view the fixed mailbox with my Win2K client, the entry appears at 9:30
* When I view my mailbox with the WinXP client that has been advanced to March 12th, the entry appears at 11:30
* When I view the fixed mailbox with the WinXP client that has been advanced to March 12th, the entry correctly appears at 10:30
Both options (using the fix code vs. doing nothing) are bad, but the "fix" actually makes things worse. If I fix all calendar entries right now, all entries for that 3-week period are 1 hour early.
Based on the above testing, the best option may be to run the fix code (for my 650 R6 users) on Sunday, March 11.
Since I have 750 R5 users that are a mix of Win2K and WinXP, and since the fix code doesn't work, I can't do anything to prevent this headache from happening. I'll have to explain to my users that "every appointment during that 3-week period is suspect".
Return to top
DST Code Doesn't Fix the Problem (Thomas J McArth... 22.Feb.07)
. . 
Print this page
