Portable general timestamp format, not 2038-limited

James Harris james.harris.1 at googlemail.com
Mon Jun 25 22:55:59 CEST 2007

On 25 Jun, 02:14, rem6... at yahoo.com (Robert Maas, see http://tinyurl.com/uh3t)
> > From:  James Harris <james.harri... at googlemail.com>
> > I have a requirement to store timestamps in a database. ...
> > 1) subsecond resolution - milliseconds or, preferably, more detailed
> How do you plan to deal with leap seconds?
> - Stick to astronomical time, which is absolutely consistent but
>    which drifts from legal time?
> - Stick to legal time (UTC), which stalls by one second from time
>    to time, causing time-difference calculations to be incorrect by
>    varying numbers of seconds?
> Only after you make *that* crucial decision, will it be reasonable
> to consider milliseconds or other sub-second resolution.

Not a problem for me. I will be taking samples and storing either
point samples or averages depending on the value being sampled. Pseudo-
GMT will be good enough. Astronimical time will be no good as the time
is to relate to the time of day the samples were taken. I think I can
just use the time as returned by the language I am using (which
presumably will get it from a C system call or similar). If one sample
over midnight when a leap second adjustment happens turns out to be
slightly incorrect it won't skew the results significantly. I could
sanity check the time, though. Hmmm.....

More information about the Python-list mailing list