[LEAPSECS] Lets get REAL about time.

[Stephen Colebourne]

On 23 January 2012 08:05, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

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


FWIW, JSR-310 handles that case, but its complex. We (currently) allow
the possibility to hold multiple versions of the time-zone rule data.
A ZonedDateTime (date and time with time-zone and offset) will
generally use the latest version of the tz rules data. But if that
make the datet-time invalid (because someone has updated the tz rule
data, user or politician), then the code will search the history of tz
rule data until it finds a rule set that does make the date-time
valid.

The leap-second case is also handles, by recording UTC as days and
nano-of-day (a flexible break in the notation that handles the
change), or by ignoring leaps via smoothing (UTC-SLS by default).


> It's the calculation of durations between timestamps on UTC in the future which is impossible, simply because they are undefined.


Not necessarily. The duration in days is well-defined, and thus a UTC
instant stored as days+nanos is well-defined for the future.

The problem here is that the meaning to a human of a point defined in
the future solely in TAI seconds will change over time. Thus TAI is of
most use solely as a clock defining now. The problem is that it is
easy for a user to get now, add 1000 * 86400 seconds to it and then
see the resulting time change over time. Thats why I (and others) see
TAI as unstable as a format for human timekeeping (useful for exact
duration based tasks, but those are relatively rare in my experience).


Reading the other mails, I think you can see where the primary concerns are:
- floating point - I and others are sceptical of that
- sole focus on TAI - for time geeks its correct and "real", but not
necessarily everyone thinks its "right"
- epoch choice - TAI, 1970 or some random choice

I think the first point looks wrong, but I'm not a kernel guy, so
thats who should guide you. A struct would be more Java-ish, but thats
probably as far as I can go.

I think you can mitigate the second objection by providing conversion
to UTC and a leapless 86400 non SI second scale in the core, and
separate from the breakdown to YMDHMS. ie YMDHMS is not the only
"broken down" form that users care about.

The third point is a detail.

Stephen