RE: Dealing with changing time

["Mark A. Manske" <mmanske@xxxxxxxxxxxxxxxxxx>]

I like this in theory - practice and implementations could be rough -

The only other thing I would add is the following -
Your database would have to keep track of the "offset"
from the QTIME data to take into account where you where
at the time the record was created as compared to the
"software"/real world clock - since we all run reports
on data that crossed the DST boundaries.

Just my two cents.
Mark

-----Original Message-----
From: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com]On Behalf Of James Rich
Sent: Friday, October 25, 2002 3:43 PM
To: midrange-l
Subject: Dealing with changing time


>From the many messages on the problems with changing time (which would
doubtless happen even if you don't observe DST) it is apparent that a
solution is needed.  Let's look at the problem:

1. timestamps in database files and logs should always increase
2. users should see time the same way the clock on the wall shows it

These two objectives are seemingly in conflict with each other.  Any
method of resolving this conflict would need to both use a constant clock
and a variable clock.  I wonder if a solution exists...

Yes, I think one does.  The iSeries has both types of clocks: QTIME and
the software clock.  An API could be developed that would convert QTIME
data into the current time based on what the software clock thinks is the
real time, and another one to convert it back again.

So let's say that you write a program to keep track of employee's time
cards.  Record all times in the DB as QTIME data and do all your math on
that data, but display it on the screen and on reports by taking into
account the software clock.  When they punch in you write to the DB
something obtained by doing:

C               time            timein

where timein is a timestamp field.  But when they look on the screen to
see when the clocked in you do something like:

C               eval    dsplytime = abstime2dsplytime(timein)

where dsplytime is maybe a char field and abstime2dsplytime() converts the
QTIME timestamp timein to the equivalent DST-aware wall clock time using
the software clock.  abstime2dsplytime() would probably make use of the
unix APIs to do its conversion.

Any comments on this idea?

James Rich


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.