[LEAPSECS] Lets get REAL about time.
phk at phk.freebsd.dk
Mon Jan 23 03:05:15 EST 2012
In message <E1Rp7gT-0003qk-DP at grus.atnf.CSIRO.AU>, Mark Calabretta writes:
>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)
Actually: Slightly _less_ than six months.
The on in june was announced on jan 5th.
>So effectively what is needed is a function to subtract two tm structs.
You can always compare them ("is date1 before, the same or after date2")
but you cannot subtract them and get a precise time-difference, if they
span a potential leap-second application.
One obvious hack is to add a "double *error" argument which is
set to the potential number of leapseconds between the two dates.
But a similar problem appears as soon as we try to compare or subtract
two timestamps in two different civil timescales, which includes
UTC in my design: Som looney politician might change the timezone
before we get there.
What the *error term should be set to in that case is anyones guess.
>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.
No, that will fail if we don't have a leapsecond table valid for
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the LEAPSECS