[LEAPSECS] Lets get REAL about time.

Mark Calabretta mcalabre at atnf.csiro.au
Sun Jan 22 19:22:53 EST 2012

On Sun 2012/01/22 19:04:05 -0000, "Poul-Henning Kamp" wrote
in a message to: Keith Winstein <keithw at mit.edu>
and copied to: Leap Second Discussion List <leapsecs at leapsecond.com>

>> Plenty of applications need to record dates

>>more than six months in the future;


>They can trivially do that, but they have to do it in a format

>that can represent the time.


>"struct tm" can do that, (if we add frational seconds to it as

>I proposed)

I agree. It is the only way that a future UTC or localtime can be

>But time_t and realtime_t can not, because they are scalar and

>the scalar number of seconds between any epoch and UTC timestamp

>more than 6 months out in the future, is undefined.

At the current rate of leap second insertion, the worst-case scenario
is that an as-yet unannounced leap second will occur in (slightly over)
6 months.

1 second in 6 months is one part in 16,000,000 which, for most (all?)
civil timekeeping purposes, is well enough defined to compute a time
interval of sufficient accuracy. In any case, as Keith implied, often
only the intended order of future events is important.

So effectively what is needed is a function to subtract two tm structs.

Currently this is done by the user by converting the two structs to
time_t and subtracting those. The implicit assumption is that that
would now be done via realtime_t. However, that need not be so. All
that is required is for users to be provided with a convenient way to
subtract two tm structs.

Regards, Mark

More information about the LEAPSECS mailing list