In message <[email protected]>, 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)
>6 months.
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
both timestamps.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email protected] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
