[LEAPSECS] Lets get REAL about time.
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 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)
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.
More information about the LEAPSECS