You know, it seems with all the problems with how DST is administered around the world, and the difficulty companies have in dealing with it, that a very low-tech answer may be more appropriate for 95% of the shops. 1) Don't worry about the DST-specific patches, which will always be problematic, due to the complexity of the problem. 2) Don't schedule escalations or allow client/server activity to occur during the hour (0200 - 0300) affected by DST changes. 3) If you can't avoid that, take the server down for "maintenance" during that hour. I know it seems like a cop-out, and in some shops that have 24 x 7 uptime requirements it may not be an option, but sometimes walking around a wall is preferable to trying to break it down. Rick _____
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Eric Cleereman (IT) Sent: Wednesday, February 21, 2007 12:17 PM To: [email protected] Subject: 6.3 Patch 20 - Issues with years prior to 2007 ** Hi All, I'm running version 6.3 of ARServer under Oracle 9 on AIX, and version 6.3 of Mid-Tier on Windows 2000 in my development environment. I've just installed Patch 20 for both, and am in the process of doing some preliminary testing. Remedy seems to be applying the revised schedule for 2007 for earlier years as well. For example, it seems to be seeing March 20th 2007 as Eastern Daylight Time (EDT), which is correct. But it seems to see March 20th 2006 as EDT as well. In 2006 EDT did not go into effect until April 2nd, so it should see that date as Eastern Standard Time (EDT). This is an issue for us, as we do a lot of historical reporting. Has anyone else running 6.3 Patch 20 (or 7.1 Patch 1) noticed any problems with Daylight Saving time calculations for 2006 or prior years? Eric Cleereman __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
