RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Records Management Program <[log in to unmask]>
Date:
Tue, 6 Feb 2007 07:55:08 -0800
Content-Disposition:
inline
Reply-To:
Records Management Program <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
From:
Larry Medina <[log in to unmask]>
Parts/Attachments:
text/plain (61 lines)
On 2/5/07, Patrick Cunningham <[log in to unmask]> wrote:
>
> Well, Y2K this ain't.
>
> The DST change is typically going to be handled by the parts of the
> programs that process and/or "read" local time zones from various parts
> of the computer systems. For PCs and servers, that is in the operating
> system for the most part, which needs to be patched. Some software may
> read the system time, but rather than see the local time, will read the
> time as GMT / UTC and convert GMT to the selected local time zone for
> that application. Clearly, if the software isn't patched, there will be
> mismatches between time zones.
>
> My guess is that somebody in your firm read this article
> http://www.networkworld.com/news/2007/012507-daylight-saving.html last
> week and saw the line about "ensuring record compliance, for example,
> could be at risk."
>
> My guess is that the big issues will be calendaring applications, plus
> some issues with document management systems where authors are creating
> documents with different time stamps.


I'm of a similar opinion on this.  Essentially, we've (at least most of the
country) had DST changes going into effect for years, the only difference
here is WHEN it takes place.  Most systems must have this accounted for as a
date/time function and all they need to do is change the date on which it
takes place within the system compared to when it USED TO TAKE PLACE in the
system.

I spoke to a friend who is a systems programmer for a large West Coast based
retailer that has stores from Hawaii to Utah, including some in states that
don't observe DST.  They have 4 time zones to deal with and this has never
been an issue for them, and he doesn't think it will be now either.

Most routine processes, such as system patches and backups are set to start
at 12:02am instead of directly at midnight because of things like this, and
DST goes into effect at 2am. Also, those that run longer than 2 hours are
rescheduled so they aren't impacted by system clock changes on DST.

He was explaining to me how they schedule processes where they "push"
information from HQ in the Pacific Time Zone out to all of their stores is
done in a "sun chaser" manner, where they start them at the farthest time
zone east of here, then run them zone-by-zone heading west towards Hawaii.
They have to "pull" information in the same manner to ensure everything they
receive accurately reflects the date on which it was transacted to comply
with Federal regulations for financial reporting and dispensing logs for the
FDA and HHS (pharmaceutical sales and orders/shipments).

Larry

Gee this is ALL so technical, I just can't IMAGINE how us little ole RIMs
are supposed to understand it!
-- 
Larry Medina
Danville, CA
RIM Professional since 1972

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

ATOM RSS1 RSS2