> - Do we still need to set the TZ setting on the Client (Windows XP OS) even though our server is HP-UX?
TZ calculations are done at the source of the display or submit. Thus, if you use a Windows client to display or submit historical data, the OS at the client (i.e. Windows) will improperly apply the historical DST rules if you do not use the TZ at the client and apply the CRT hot fixes. This is shown in Figure 1-1 and 1-2. Note that the server says "Any OS" which means Any OS... Unix or Windows. Therefore yes, you would have to use the TZ on the client even if your server is HP-UX to address this issue. No changes have to be made on the Unix Server for this historical date issue since Unix Servers don't appear to have an issue with applying DST rules based on year. > - Do our client PCs need the MSVCRT.DLL hotfix or is that a Windows server only fix? Every affected Windows system, client or server, would need the hotfix and use the TZ variable to address the historical date issue. So it is not only a Windows Server fix - it is also a Windows Client fix. -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 Kendhammer, Mike Sent: Friday, March 09, 2007 8:39 AM To: arslist@ARSLIST.ORG Subject: Re: Additional information about DST event and how it affects AR System I still have a few questions that I am unclear on regarding the technical bulletin... We are on 6.0.3 patch 20... - Do we still need to set the TZ setting on the Client (Windows XP OS) even though our server is HP-UX? - Do our client PCs need the MSVCRT.DLL hotfix or is that a Windows server only fix? Thanks! Mike -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Friday, March 09, 2007 8:55 AM To: arslist@ARSLIST.ORG Subject: Re: Additional information about DST event and how it affects AR System 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" ________________________________________________________________________ _______ 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"
