I am surprised there has not been more of a stir over the changes to DST next year. If I am reading this right, many scheduling items could be broken (wrong time) next year if OS’s don’t get updated promptly. My question is whether the client OS time really matters. If mail files are on the server and the server’s OS is patched for new 2007 rules, is that enough?
Subject: DST Changes in 2007 - Support Links and a Question
I have just started to test with a client of mine who is a mixed 6.5.4 and 6.5.5. We have come across a number of issues around DST. We have moved some of our test servers and workstations forward and found 2 issues.
The first one is the agent manager somehow gets out of whack. For the entire day after the time change the agent manager is out by one full hour. Therefore your agents that are scheduled to run at 6:00 will actually run at 7:00. The good news is that at midnight the following night, the system resolves itself. We have a PMR open with Lotus and they have been able to reproduce the error and are now working on the fix - I will post an update here when I hear back.
The second issue is around DWA. DWA compares the users TimeZone to what is stored in the Calendar Profile (Preferences in DWA). When the workstation is patched with the Microsoft operating system fix, an error message starts to appear stating that ‘timezones do not match, use Preferences to update’. Lotus has a solution for this where you update Forms6.nsf:
Unfortunately this fix then breaks iNotes/DWA for those users that have NOT applied the Microsoft operation system patch. Making the changes to Forms6.nsf just reverses who gets the error. We have a PMR open for this problem now as well and I will update this thread if we get a resolution. Unfortunately for large companies like the one I am at now, updating all 30,000 desktops at the same time is next to impossible.
Subject: RE: DST Changes in 2007 - Support Links and a Question
I opened a pmr with Lotus on this about two years ago and was told it was working as designed and they would do nothing to fix it. So, last year, I had to manually change the time of each and every agent for that day to run an hour earlier, so it would actually run on time. I have many processes that are time dependant and they must run at the right time. Of course that meant I needed to change them back manually for the next run of the agent. Just tracking down all the agents that would be affected was a major hassle. Fortunately, I only had 2 servers that I needed to be concerned with. But I’m looking at having to do the same thing again this year. A nice ‘feature’ huh? Sounds like a major bug to me!
Subject: DST Changes in 2007 - Support Links and a Question
As long as we change the computer clock time we are all set. Regarding any intelectual applications that they are not confined to the OS time, then there is a chance it might be get affected. And I believe we all learned our leassons in the 2000 millaneum bug and no one will be hardcoding anything anymore, if developed by real professionals.
This is my 2 cents and I could be 100% wrong, better test the systems before March11.
Subject: RE: DST Changes in 2007 - Support Links and a Question
Hi,
The computer clock will be ok, but you will have to do it manually for every computers, 2 times a year (march, november) , every year. In some company, you are not allowed to modifiy this setting. The DST setting is stored in the registry. If you have 10 computers, it could be ok, but with 25000 computers…
Dates in Domino are stored with a memory of the DST rules as they existed when the document was saved
– Meetings that exist in calendars today on the ‘new’ DST dates are affected and need to be updated by an agent.
Agents are currently in developement by IBM, have a look in the knowledge base.
It’s not an IBM problem, every piece of software (Notes, Outlook) or hardware (Client or server, handheld devices) or OS (Windows, Linux, SUN) is at risk.