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”.
My environment is slightly different, but my problem is the same (with one addition).
I have updated the OS on all servers and clients.
Servers = 2000 and 2003 Domino 6.5.4
Clients = Windows XP SP2 Notes 6.5.4
I ran the R&R agent and the C&S 4.0.2.4 agent. The next day lots of people calling me saying their meetings during the extended period were off by one hour. My response “would have been”…please manually reschedule them then. Weird that they are appearing wrong because all of the agents processed successfully hundreds of documents.
Here’s the real problem. When users on my EST time servers (2000 & 2003) create a “new” calendar entry and save it during that 3 week period…it displays one hour earlier in the calendar view, but when you open it its fine. This is not happening for my MST users (unless they create a calendar entry in a different time zone and choose EST…then the meeting is 3 hours off instead of the normal 2).
I’m in the same boat you are. I’ve been working on getting all of the DST stuff implemented over the last week so we would be ready for March 12th. Looks like we won’t be and I’ll have to tell my users to schedule their meetings one hour later than they really want it to appear. That’s stupid!
I reran my test using the latest version of the admin fix code (4.0.2.6). The appt times are still off by 1 hour on my test WinXP machine that has had the date advanced to March 12th. When I look at those same appointments from a production machine, they appear at the correct times.
Both the StartTimeZone and EndTimeZone fields (in the modified appointments) have the following value: Z=5$DO=1$DL=4 1 1 10 -1 1$ZX=25$ZN=Eastern
The code checks only the Z, DO, DL, and ZN parameters, as the ZX parameter is not significant in this case for Notes clients, and is unused for Domino Web Access sessions. If the field matches one of the above values, the DL parameter will be updated to contain “DL=3 2 1 11 1 1”, reflecting the new DST rule, and the Z, DO, ZN parameters (and for Notes created entries ZX) will remain unchanged. We then rebuild the StartDateTime and EndDateTime fields, based on the new StartTimeZone and EndTimeZone values. We will also set a new field, $TimeZoneAgent with a value of 1, to track which documents the agent has processed.
My documents were created using an R6 (or greater) client on an R6 mailbox that lives on an R6 server. Since the code is supposed to fix R6 calendar entries, but these R6 calendar entries are broken, then the “fix” code must have broken them.
Hence, my original point stands: the fix code does not do what it promises to do.
You ran with version 4023 first? When the code runs, it will add a field called :$TIMEZONEAgent
Like I said in one of my post, you should have this value
The code checks only the Z, DO, DL, and ZN parameters, as the ZX parameter is not significant in this case for Notes clients, and is unused for Domino Web Access sessions. If the field matches one of the above values, the DL parameter will be updated to contain “DL=3 2 1 11 1 1”, reflecting the new DST rule, and the Z, DO, ZN parameters (and for Notes created entries ZX) will remain unchanged. We then rebuild the StartDateTime and EndDateTime fields, based on the new StartTimeZone and EndTimeZone values. We will also set a new field, $TimeZoneAgent with a value of 1, to track which documents the agent has processed.
So the agent is not “processing” your documents. Have you tried the debug mode?