"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___
