I have no way to test my 5.1.2 production server since my dev server has already been upgraded to v7.0. Has anyone actually tested 5.1.2 (Patch 1428 or lower)?
Are they actually referring to date/times in data fields on the records? Trying to think about what we import and if we can live for those 3 weeks. I apologize for my ignorance, but is that library something you can look at to see if it has whatever component would be causing the problem? What file is it? Where is it? What would you look for in the file if that's possible? Thanks, Susan On 2/20/07, Mike White <[EMAIL PROTECTED]> wrote:
"Regarding Mike's comments, so we need an update to all our PC's to take care of DST issues from the client perspective, which could make it look like ARS isn't putting the right date in client date/time generated fields. Correct? " Yes. And also true - it would appear that Remedy "isn't putting the right date...". We're running 6.0.1, patch 1497 on Solaris 5.9 with an Oracle 9i db. I hear that it's the same for 5.1.2 (didn't get the patch level). The trickier part of MS Windows patch install is synchronizing it to minimize the time that you have a mix of patched and unpatched workstations among your Remedy users. Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] "Susan Palmer" <[EMAIL PROTECTED] To: arslist@ARSLIST.ORG L.COM> cc: Sent by: "Action Subject: Re: DST Request System discussion list(ARSList)" <[EMAIL PROTECTED] ORG> 02/20/2007 14:31 Please respond to arslist ** Both David Easter's comments and Mike White's bring additional light to the subject. So there is a file within ARS that knows when DST is/was supposed to be. Does that file exist in v5.1.2 P1428? That's pertinent to me. My dev server is already upgrade to v7 no patch and there's been a large delay in doing the production server so I'll probably patch the dev server before that. But you hear more bad about 7.01 than 7.0 which makes me uncomfortable, but apparently you can only get the DST fix if you go to 7.0.1 patch xx. Regarding Mike's comments, so we need an update to all our PC's to take care of DST issues from the client perspective, which could make it look like ARS isn't putting the right date in client date/time generated fields. Correct? I was pretty sure there was nothing in Remedy to cause an issue and we have a project to collect data regarding DST for everything we run/run on. So I thought I should check some postings ... thank goodness. Prudence pays ... thank you to whoever was whispering in my ear! Susan On 2/20/07, Mike White <[EMAIL PROTECTED]> wrote: The key is "deployable applications". Exporting search results to a .csv or .arx file is altogether different. We've tested each and didn't see any problems. To David Sander's point - "yes", the client plays a significant role. Not only regional and language settings, which govern timezone and 12/24-hour display format, but also the MS Windows DST patch. Patched users and non-patched users see different values (1-hour difference) in the sensitive time periods (03/11/07 through 04/01/07 and 10/28/07 through 11/04/07 for this year, for example). What may be in dispute is patch scope. Our testing uncovered what looks like a retroactive implementation. Past years' date/time values are 1-hour incorrect if in a "change range" (if MS Windows DST patch installed). Another lister posted results that contradict this, which I've asked to confirm (specific comparison of patched vs. un-patched client workstation, viewing same record, with past year's date/time value, in what would have been in offending range, if the change had been in effect then). 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: DST Request System discussion list(ARSList)" <[EMAIL PROTECTED] ORG> 02/20/2007 13:34 Please respond to arslist ** My understanding is that in testing of 6.0.1 for the effects of the DST 2007 event, BMC found that during the import/export of deployable applications that date/time fields within the application were affected by the event (in other words, times were off by one hour). The import/export process uses an XML parser which, itself, references a library that performs date/time related calculations - including DST. This library maintains information about when DST happens each year, and an updated version of this library was not made available from the 3rd party vendor for the version used within AR System 6.0.01. This is why import/export is affected. I may be slightly off in the technical wording, but that is the general thrust of the issue. 6.03 and 7.0.01 use later versions of this library and these more recent versions were patched by the vendor - which are in turn being provided to BMC customers within 6.03 patch 020 and 7.0.01 patch 001. 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 David Sanders Sent: Tuesday, February 20, 2007 10:05 AM To: arslist@ARSLIST.ORG Subject: Re: DST ** Hi Susan I'm confused by this too. Dates are stored in the Remedy database as epoch time (number of seconds since 1/1/1970 12 AM GMT). A change to DST should not affect dates in the DB. The potential problem is with the client and how it displays the date locally – it might be an hour off. Data exported in ARX files contains the epoch time, not a locally formatted date/time representation, so again, should not be affected by DST. If you export to a text/csv format, the timezone of the client may come into effect, and if you import from a text file with formatted dates, again you might have a problem. But if you stick to ARX files, I don't see what the problem is. Regards David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== ARS List Award Winner 2005 Best 3rd party Remedy Application tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Susan Palmer Sent: Tuesday, February 20, 2007 5:48 PM To: arslist@ARSLIST.ORG Subject: Re: DST ** I just finished perusing that bulletin. To piggy-back on Mary's questions ... I'm curious how DST can affect import/export times. I wouldn't have thought DST would affect anything if your server is set correctly. I understand there are exceptions if other servers are involved and where people are located etc. But for the most part, why should this year be any different for the basic ARS system than last year. Is there some hidden code written in there that gives the DST date for every year? Where is the import/export facilities taking their date/time from if not the server or I guess the client? Thanks, Susan On 2/19/07, Easter, David <[EMAIL PROTECTED]> wrote: > Is that all that is affected? As far as BMC knows, everything that is affected on 6.0.01 is listed in the technical bulletin found at: http://www.bmc.com/supportu/documents/78/29/67829/67829.pdf Thanks, -David J. Easter Sr. Product Manager, Service Management Business Unit BMC Software, Inc. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG ] On Behalf Of Mary C. Sent: Friday, February 16, 2007 5:04 PM To: arslist@ARSLIST.ORG Subject: DST I read, therefore I am confused. I have 2 questions about this document: http://www.bmc.com/USA/Support/attachments/BMC_DST_Summary_2007_02_15.pd f 1. For ARS 6.01 it states that the Operational Impact if not fixed is "Web Services and Import/Export time calculations will be off by 1 hour." Is that all that is affected? So normal ticket updating of resolution time, Change Request Actual Request time, etc., will NOT be affected? Only Web services, Import & Export? 2. We use Crystal Reports integrated with Remedy. I don't know that much about it, but does Crystal "export" the records out of Remedy? Thanks. ________________________________________________________________________ _______ 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" __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"