RE: Dealing with changing time

Ohh, thats gotta be a nasty API, but then again
I can just imagine how ugly the date API's are.
So if the API knows it, great, let the super
geeks help out us mediocre geeks.

<can you tell its getting late on a Friday for me>

Anything to make time/date easier, I am all for.

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 4:11 PM
To: midrange-l@midrange.com
Subject: RE: Dealing with changing time


On Fri, 25 Oct 2002, Mark A. Manske wrote:

> 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.

No, you wouldn't.  That what the unix APIs do (or should, given the right
info).  Probably something like gettimeofday().  You give it the QTIME
data and the APIs know what the corresponding wall clock time would have
been (or will be).

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.