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:
Mon, 5 Feb 2007 19:55:09 -0800
Reply-To:
Records Management Program <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
multipart/related; boundary="0-1373704745-1170734109=:84368"
From:
Patrick Cunningham <[log in to unmask]>
Parts/Attachments:
text/plain (1265 bytes)
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.



Patrick Cunningham, CRM
[log in to unmask]

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin, Historical Review of Pennsylvania, 1759

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

ATOM RSS1 RSS2