Is there anyone out there with 5.1.2 (Patch 1428 or lower) that has tested for DST issues? What were the results.
Appreciate your feedback, Susan Server: ARS 5.1.2 Patch 1428 OS: Windows NT 5.0 2CPU's 4G Memory Database: Oracle 9i2 User: ARS 5.1.2 Patch 1316 User OS: XP, NT, Win 2000 Admin: ARS 5.1.2 Patch 1289 Crystal that created reports: 9 On 2/20/07, Susan Palmer <[EMAIL PROTECTED]> wrote:
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 <http://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"
