> By TZ variable, do you mean Date and Time setting within Control Panel?
Details of how to set the TZ variable are at the end of that section. Basically, for the client, set it in the Remedy User Tool Options or use a preference server. For an AR System Server, set it at the command line with the 'SET' command prior to launching AR System. 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 Mike White Sent: Friday, March 09, 2007 11:47 AM To: arslist@ARSLIST.ORG Subject: Re: Additional information about DST event and how it affects AR System Sorry, David. I don't mean to be thick, but part of this confused me: "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." By TZ variable, do you mean Date and Time setting within Control Panel? The reason I ask is that we'd installed the MS WIndows (XP) Hot Fix and also have the correct time zone set on our workstations, and on our server, we included the variable (TZ=US/Eastern), but historical date/time values in the offending ranges are still incorrect. In other words, setting TZ didn't fix it. At least in either of these two places. Did I misunderstand? We're running ARS 6.0.1, patch 1497 on Oracle 9i (Soalris 5.9 server OS). Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] "Easter, David" <[EMAIL PROTECTED] To: arslist@ARSLIST.ORG .COM> cc: Sent by: "Action Subject: Re: Additional information about DST event and how it affects AR Request System System discussion list(ARSList)" <[EMAIL PROTECTED] ORG> 03/09/2007 11:49 Please respond to arslist By the way, there's a couple of typos in the bulletins that will be corrected within the next 24 hours. In the areas where the historical date issue are described, sometimes the bulletins incorrectly state "years prior to 2006" when they should read "years prior to 2007". In other words, the historical date issue affects dates in the year 2006 and years prior to 2006. 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 Easter, David Sent: Thursday, March 08, 2007 8:19 PM To: arslist@ARSLIST.ORG Subject: Additional information about DST event and how it affects AR System 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_1969 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_4073759 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" ________________________________________________________________________ _______ 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"
