[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

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)

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