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