But you can't migrate to a non-MS OS and use Remedy. That is the only OS that supports the Remedy clients (user, alert, admin). Good news is that MS's black Tuesday falls on the 8th, giving you several days to address the issue, assuming a patch is relesed. Sorry, couldn't resist.
Axton On 2/21/07, Eric Cleereman (IT) <[EMAIL PROTECTED]> wrote:
** David, Thank you for pointing me in the right direction. This does seem to happen with other (non-Remedy) apps as well. So at this point, it seems we have the following options: 1) Live with it until MS or a third party offers a solution 2) Utilize Windows Vista as an enterprise server (tongue very much in cheek) 3) Migrate to a non Microsoft OS 4) Live with it indefinitely Option 1 doesn't look promising, as it appears that Microsoft is side stepping ownership of this. Here's an excerpt from http://msdn2.microsoft.com/en-us/vstudio/bb264729.aspx: Applications that deal with historical time zone data may also need to be updated. Microsoft advises all developers who make use of time zone data to test their applications against this update to ensure that their applications function correctly. We'll evaluate options 3 and 4. Thanks again. Eric -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Easter, David Sent: Wednesday, February 21, 2007 3:56 PM To: [email protected] Subject: Re: 6.3 Patch 20 - Issues with years prior to 2007 ** Also, please check if other applications are behaving in this manner. Hopefully this will not sound like I'm pointing fingers, but I have seen several comments within Microsoft blogs that indicate that the DST patch for Windows encounters this issue - namely that the DST "fix" is not year dependant, so that data from previous years picks up the DST schedule for 2007. See: http://www.jnbridge.com/blog/?p=23 "There's a very interesting problem with Microsoft's DST patch for Windows that you should be aware of, since it can impact date conversion results when mapped date proxies are used. The patch applies the new rules for whether date and time are daylight savings time without regard to year. This means that if you ask .NET whether a given DateTime in the past is DST, it will apply the new rules even if the date would have been standard time under the old rules." and http://blogs.msdn.com/michkap/archive/2007/02/05/1606868.aspx "Apparently we were naïve, as now historic times are calculated incorrectly due to Windows inability to calculate the correct DST times from previous years, including 2006! You can try it for yourself, by changing the system clock to March 13th 2006 on a Windows XP machine (or 2000 machine with manual registry patch as suggested in KB914387). Vista gets it right, but as that represents < 0.1% of our install base it's not much consolation at the moment." Again, I'm not saying that this is the case, but it's something to test for - namely whether the issue you are seeing was caused by the AR System patch or happened when you loaded the OS and/or Java patches. Since AR System in general uses the Operating System for DST information except for the Mid-Tier, web services and import/export; DST 2007 issues seen in other parts of AR System are potentially linked to the DST changes in the Operating System itself. Thanks, -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick W Sent: Wednesday, February 21, 2007 12:38 PM To: [email protected] Subject: Re: 6.3 Patch 20 - Issues with years prior to 2007 ** Just to check ... On the AIX box you have - The AIX DST patches applied - The updated Java - The ARS server patch On the Windows box you have - The Microsoft DST patches applied - The updated Java - The ARS Mid-Tier patch ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Eric Cleereman (IT) Sent: Wednesday, February 21, 2007 2: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___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
