Susan,
I've watched your recent posts on DST and hoped that Cherian Thomas
would chime-in. He's running ARS 5.1.2 as well, but he didn't share his
patch level. He'd contacted me off-line with similar questions.
Summarized, he got the same results as I did on 6.0.1. The keys are server
OS and MS Windows DST patches. No doubt you'll want more detailed info -
hopefully Cherian can fill in your blanks.
His e-mail address is [EMAIL PROTECTED]
Mike White
Office: 813-978-2192
E-mail: [EMAIL PROTECTED]
"Susan Palmer"
<[EMAIL PROTECTED] To: [email protected]
L.COM> cc:
Sent by: "Action Subject: Re: DST
Request System
discussion
list(ARSList)"
<[EMAIL PROTECTED]
ORG>
02/21/2007 10:30
Please respond to
arslist
**
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:
[email protected]
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:
[email protected]
.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: [email protected]
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:
