A Date-Time format stored as Days
Scott David Daniels
Scott.Daniels at Acm.Org
Thu Mar 7 16:55:10 EST 2002
While many Linux / Unix systems represent time as a number of seconds since a
base time. One big problem with this format is that, while differences are easy to
calculate, it does not incorporate "leap seconds" gracefully at all.
A representation of a Date-Time as Days and seconds within day is better, but
differences are tougher to calculate, and naive code breaks badly in the presence
of leap seconds.
A representation as A Day / fixed point fraction of a day should work much better.
In a system that ignores leap seconds, this is simple. The low word (fixed point
day fraction) can simply be multiplied by a constant to convert it to seconds. If
there _are_ leap second records, they affect the day fractions of certain days.
This is usually reflected as a scaling providing an extra second on a particular
day. In rare cases, certain days have _two_ leap seconds, so there are three
scale factors converting day parts to seconds: normal days, leap-second days,
and double-leap-second days. The differences between the factor for double-
leap-second days and normal days is 2 seconds in 24*60*60 or 1 part in 43200.
This "error" is spread smoothly across the day, so that naive difference of two
date-times is quite close to the leap-second aware difference.
By calculating in units of days, we can do quite well in avoiding running into
the leap-second problem. With 64-bit hardware, we can quite nicely use the
high order 32 bits for a day and the low order 32 bits to get a very high-precision
day part, and simply use integer math to do most calculations.
-Scott David Daniels
Scott.Daniels at Acm.Org
More information about the Python-list
mailing list