[LEAPSECS] Lets get REAL about time.

Poul-Henning Kamp 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)

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

More information about the LEAPSECS mailing list