[LEAPSECS] Lets get REAL about time.

[Mark Calabretta]

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
stored.


>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