If you use TZ -and- load the hot fix from Microsoft for MSVCRT.DLL, then the historical data issue will not occur.
If you just use TZ, you will see the historical data issue. Thanks, -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kyle Whitley Sent: Friday, March 09, 2007 5:44 AM To: arslist@ARSLIST.ORG Subject: Re: Additional information about DST event and how it affects AR System > > For AR System 6.03 or 6.0.1: "If your client and/or server needs to be > set to use a United States time zone, you will need to load a hot fix > from Microsoft and set the TZ variable at your client or server. > Failure to do this will cause some displayed and submitted historical > dates to be off by one hour." David, Does this mean if we are setting our clients with a TZ that these issues should not occur? Thanks Kyle Easter, David wrote: > Hi All, > > As mentioned on this list, we've discovered another consequence of > the start/end date shift in DST for the US/Canada that is caused by a > deficiency in the Microsoft Operating System. Due to the heightened > sensitivity to DST related issues has worked directly with Microsoft > to provide a solution to our customers. BMC has updated the technical > bulletins for DST found on Support Central to reflect this new > information and document the potential solution available from BMC and > Microsoft. > > Because of the complexity of the situation, the technical bulletins > have now been broken up into three versions - representing the three > supported versions of AR System currently available (i.e. 6.0.1, 6.03, > 7.0.01). AR System 5.1.2 customers should read the 6.0.1 technical > bulletin as 5.1.2 and 6.0.1 will exhibit nearly the same symptoms. > Please read the bulletins carefully - information within the bulletin > varies by version, so answers for one version may not apply to another > version. The bulletins are posted at > http://www.bmc.com/support/hou_Support_AZ_List/#R under AR System and > the appropriate version. [Due to a back-office glitch, some bulletins > may not be available until after 9pm CST on 3/8/07 or later...] > > The short summary of the additional information in the technical > bulletin is this: > > For AR System 7.0.01: "If your client and/or server needs to be set to > use a United States time zone, you will need to load a hot fix from > BMC (or patch 002) and set the TZ variable at your client or server. > Failure to do this will cause some displayed and submitted historical > dates to be off by one hour." > > For AR System 6.03 or 6.0.1: "If your client and/or server needs to be > set to use a United States time zone, you will need to load a hot fix > from Microsoft and set the TZ variable at your client or server. > Failure to do this will cause some displayed and submitted historical > dates to be off by one hour." > > The more detailed explanation is as follows: > > Windows Update distributes Windows operating system fixes that will > make sure clocks are adjusted correctly moving forward. However, this > Microsoft-supplied operating system patch resolves only the DST issue > for 2007 and itself introduces an additional DST-related defect. After > the operating system is patched, historical data might be incorrect. > Because AR System stores and processes historical data, it is affected. > > Details: Microsoft Windows 2000, XP, and 2003 store only one set of > DST rules for each time zone. If you display or submit a date in the > past that falls into the weeks involved in the DST changes, a call is > made to the operating system to obtain local time. This call to the > operating system applies the new 2007 rules to historical dates and is > off by one hour. Based on conversations between Microsoft and BMC, > Microsoft is looking at a Design Change Request (DCR) for storing > multiple DST rules, but this change is not guaranteed and, even if > created, is not expected to be available before this summer. > > This discrepancy affects historical dates in the years prior to 2007 > (that is, 2006 and earlier). The range of dates affected varies from > year to year as defined by the new DST 2007 rules, which include these > statements: > > - DST will begin on the second Sunday in March instead of the first > Sunday in April. > - DST will end on the first Sunday in November instead of the last > Sunday in October. > > Thus dates between the second Sunday in March and the first Sunday in > April for years prior to 2006 will be affected. In the same way, dates > between the last Sunday in October and the first Sunday in November > will be affected. > > Note that this issue will occur independently of the current time and > date. Thus the issue can be seen immediately after installing the > Microsoft operating system patch and will continue even if the current > local date is beyond the discrepancy between legacy and new DST dates. > > There are pretty pictures in the technical bulletins that show the > issue, but simply put the effects are as follows: > > For Remedy User; if the time zone is not set through the AR System > User Preference form or preference server, the following behavior occurs: > > - For Standard Time to Daylight Saving Time, BMC Remedy User will > display data as one hour earlier than what is stored in the database > for dates between the second Sunday in March and the first Sunday in > April in years prior to 2007. The opposite occurs (i.e. time will be > one hour > later) when the date is in the Daylight Saving Time to Standard Time > shift. > > - For Standard Time to Daylight Saving Time, the data submitted from > BMC Remedy User will be written to the database as one hour later than > what is in the submitted field for dates between the second Sunday in > March and the first Sunday in April in years prior to 2007. The > opposite occurs (i.e. time will be one hour less) when the date is in > the Daylight Saving Time to Standard Time shift. > > The same thing happens on the AR System server. If the operating > system environment variable TZ is not set, the following behavior occurs: > > - Std to DST: Data written by the server within the server itself (for > example, through a push field or related workflow) will be one hour > later than what is expected for dates between the second Sunday in > March and the first Sunday in April in years prior to 2007. DST to > Std is the opposite (time will be one hour earlier). > > - Std to DST: Data read from an existing field by the server for use > within workflow will be one hour earlier than what is in the field for > dates between the second Sunday in March and the first Sunday in April > in years prior to 2007. DST to Std is the opposite (time will be one > hour later). > > The fix is a replacement of some system DLL's (msvcp71.dll & > msvcr71.dll for 7.0.01 and msvcrt.dll for 5.1.2 - 6.03) and the fix > requires no code changes to AR System. In other words, the files are > MSFT files that can be dropped onto a system without requiring another > patched version of AR System beyond the already distributed patches. > It does, however, require using either the TZ environment variable > from the OS or setting the timezone within the user tool preferences (or a preference server). > > As mentioned above, for 7.0.01 you can contact BMC to obtain the > corrected msvcp71.dll & msvcr71.dll. For customers on 6.03 or > earlier, you'll have to contact Microsoft. The KB for obtaining > msvcrt.dll is http://support.microsoft.com/?id=932590. > > One gotcha is that Microsoft is only supplying the fix at no cost for > Windows XP and Windows 2003 [and Vista - but Vista doesn't have the > original problem]. They will offer the fix for $4000 USD for > customers running Windows 2000 (Win 2K is out of it's primary support window). > They have not indicated to BMC that they'll provide the fix for any > other operating systems. So if a customers is running Windows NT, > Windows ME, Windows 98 or other older operating systems, the customer > will have to contact Microsoft directly. > > Thanks, > > -David J. Easter > Sr. Product Manager, Service Management Business Unit BMC Software, > Inc. > > The opinions, statements, and/or suggested courses of action expressed > in this E-mail do not necessarily reflect those of BMC Software, Inc. > My voluntary participation in this forum is not intended to convey a > role as a spokesperson, liaison or public relations representative for > BMC Software, Inc. > > > > > > > > > > > > > ________________________________ > > From: Easter, David > Sent: Thursday, February 01, 2007 4:54 PM > To: Virtual Team - Remedy; Virtual Team - Service Management > Subject: Additional information about DST event and how it affects AR > System > Importance: High > > > All, > > I posted this previously, but we're still getting a flood of E-mails > asking questions answered in the tech bulletin, so I will post it again. > PLEASE READ IT! Not only does it describe the patches needed for AR > System 6.3 and 7.0.01, the bulletin also contains information about > the effects of not patching or upgrading systems. It can be also be > found on Support Central in the documentation section for AR System: > > Documentation section for AR System: > http://www.bmc.com/support/hou_Support_ProdAllVersions/0,3646,19097_19 > 69 > 5_108018_0,00.html > Specific link to Technical Bulletin: > http://www.bmc.com/supportu/documents/78/29/67829/67829.pdf > > The most common additional question that comes up is "Can I get the > same information for 5.1.2?". The answer at the moment is that 5.1.2 > will most likely encounter similar effects as documented for 6.0.1. > However, since 5.1.2 is unsupported, BMC has not done any testing > specifically on 5.1.2. 5.1.2 customers should review the technical > bulletin and review the documented effects of the DST event on 6.0.1. > Customers may find that they are minimally or not at all affected. > > (For those that didn't know 5.1.2 was unsupported, you can review the > support policy for BMC at: > http://www.bmc.com/info_center_support/overview/0,,19097_4736154_40737 > 59 > 6,00.html) > > The second most common question is "Why aren't we patching 6.0.1 if it > that release supported?". The quick answer to this question is: "The > affected library in AR System is provided by a 3rd party vendor. The > AR System patches for 6.03 and 7.0.01 are passing the DST updates to > that library from that vendor to our user base. However, the vendor > that provides this library is not providing a patch to the version of > the library used in 6.0.1. Thus we cannot provide a fix for 6.0.1. > That being said, the use of the affected library was minimal in AR > System > 6.0.1 and the two primary affected areas are web services and > import/export. AR System 6.0.1 customers not using web services or > import/export may be minimally or not at all affected. Please review > the technical bulletin for more details on the documented effects of > the DST event on 6.0.1." > > As with anything of this nature, BMC strongly recommends that > customers test the effects of the DST 2007 event in their development > environment to fully understand what impact the DST event will have on > their environment. > > Thanks, > > David J. Easter > Product Line Manager BMC Software <http://www.bmc.com/> > AR System - BMC Service Management Business Unit > +001 (408) 571-7384 > > > > > > > > > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > ARSlist:"Where the Answers Are" > > -- Kyle Whitley IT System Support Professional Office of Information and Instructional Technology (OIIT) Board of Regents of the University System of Georgia ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
