Agents for DST Fix some Calendars but not Others

HCL Domino Domino Forum
1

I used the admin agent (version 4.0.2.6) on all my users’ mail files to correct entries that are off by an hour because of the DST changes.

Some calendars were corrected and some were not. The ones that were not still show the entries an hour later in the calendar view. Then when I open the entry, it shows the correct time.

A new agent was released so I ran the newer agent (4.0.2.7) on the calendars that were not corrected. There was no change. I used the View and Select agents (4.0.2.7) on a few calendars but that did not correct the entries either. I cannot find anything consistent about the calendars that are not getting corrected. Some of the calendar entries were entered way back in September, others in January or February.

All of the workstations received the DST patch via our Windows WSUS server in November. I ran the TZEdit tool on our Windows 2000\Domino server in January, corrected the Forms6.nsf file and removed the DSTLaw variable in the INI. All of our workstations have Notes 6.5.5.

Has anyone else run into this? Any ideas?

Thanks,

Greg

2

Subject: Agents for DST Fix some Calendars but not Others

Hi Greg,

Is the StartTimeZOne\EndTimeZOne fields correct? You should have DL=3 2 instead of DL=4 1.

Do you have a field called $TimeZoneAgent?

If the value of $TimeZoneAgent=0 , you have a problem.

From Agents for updating Calendaring and Scheduling entries and Resource Reservation entries for Daylight Saving Time (DST) 2007

The StartTimeZone and EndTimeZone fields are structured to contain the following attributes:

Parameter

Definition

Z

Time zone offset from GMT.

DO

Daylight Saving Time (DST) observed flag. 1 means DST is in effect; 0 means it is not. If equal to 1, a value should be supplied for DL.

DL

DST law identifying the .

ZX

Host-specific time zone index. Note: This parameter is not generated in Domino Web Access-created entries.

ZN

Time zone name.

The agents check the StartTimeZone or EndTimeZone to see if they match any of the values in this list:

“Z=9DO=1DL=4 1 1 10 -1 1ZN=Alaskan”
“Z=8DO=1DL=4 1 1 10 -1 1ZN=Pacific”
“Z=7DO=1DL=4 1 1 10 -1 1ZN=Mountain”
“Z=6DO=1DL=4 1 1 10 -1 1ZN=Central”
“Z=5DO=1DL=4 1 1 10 -1 1ZN=Eastern”
“Z=4DO=1DL=4 1 1 10 -1 1ZN=Atlantic”
“Z=3003DO=1DL=4 1 1 10 -1 1ZN=Newfoundland”

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.

JYR

3

Subject: Agents for DST Fix some Calendars but not Others

Greg,

Have your users always been R6 or some were upgraded from R5 recently? I’m asking because the agent will not process R5 documents by default. You have to set the ProcessR5 variable to True in the User Definable variables section of the agent. Even if the mailfile template of those users is now R6, the documents created when it was R5 are still R5… You can confirm that by looking for the StartTimeZone and EndTimeZone fields in the doc properties. If they are not present, it’s an R5 entry.

Also, as Jean-Yves pointed out, the agent leaves a flag in the documents it processed, but if nothing was updated then that shouldn’t matter since that means the agent didn’t go through those documents (hence didn’t set that flag to 1), but in case it did, check the doc properties of an entry that didn’t get updated and confirm that the field $TimeZoneAgent is not there. If it’s there you will have to set it to 0 for the agent to process that document again. A small agent could do that easily.

4

Subject: RE: Agents for DST Fix some Calendars but not Others

Hi Greg.

JYR

5

Subject: RE: Agents for DST Fix some Calendars but not Others

Some of the databases used R5 templates when the appointments were entered and then were upgraded to R6 in December. Some did not have the StartTimeZone or EndTimeZone fields, some other entries do.

In the DST agents, I changed the line to ProcessR5=False to ProcessR5=True. The user agent now corrects some of the calender entries. But even that didn’t correct all of the entries in same month. For example, there are repeating entries on one calender for each Tuesday of the month. The tool corrected the entry for March 27 but not March 20.

Any thoughts on that?

Thanks,

Greg

6

Subject: RE: Agents for DST Fix some Calendars but not Others

We’ve had similar issues like this. They all have R6, and they all had the 4[1].0.2.4 version of the DST agent ran on them. We found somewhere online, that for Windows 2000 users, you have to change the OS time zone to something other than what it is supposed to be. Apply the change, then change it back. This should be done while Notes is closed. We’ve also had to so this on some XP users as well. This resolved the probelm.Good luck.

7

Subject: RE: Agents for DST Fix some Calendars but not Others

We are having same issue as Greg. Some calendar entries were corrected with agent and some were not. They show the entries an hour later in the calendar view. Then when I open the entry, it shows the correct time.

What to do?