[LEAPSECS] Running on TAI

[Martin Burnicki]

Steve Summit wrote:
> Martin Burnicki wrote:
>> Just a few general thoughts based on an internal note...
> 
> And some very good points they were.
> 
>> ...The same applies to the time_t type, IMO. If you let the system kernel
>> run on TAI or whatever then the time() function still returns a time_t
>> data type, but its value represents TAI or whatever has been configured.
> 
> Right... but you may or may not be skating on thin ice!
> 
> I think the question of "Must time_t represent UTC?" can be
> a pretty illuminating one, and it cuts across several of the
> fundamental issues here.  Strictly speaking, the Posix definition
> of time_t is, as Warner Losh has argued, very specifically UTC.
> (And of course it's also a very specifically non-UTC form of UTC.)

Hm, maybe that was originally the case. I wonder whether the folks who
wrote the text just had UTC in mind when they "invented" time_t.

As I've mentioned earlier, also "struct time_spec" has a time_t field,
and the page
http://pubs.opengroup.org/onlinepubs/7908799/xsh/clock_settime.html

says:

"All implementations support a clock_id of CLOCK_REALTIME defined in
<time.h>. This clock represents the realtime clock for the system. For
this clock, the values returned by clock_gettime() and specified by
clock_settime() represent the amount of time (in seconds and
nanoseconds) since the Epoch. An implementation may also support
additional clocks. The interpretation of time values for these clocks is
unspecified."

So IMO this clearly says that time_t has to be interpreted depending on
the context, and must not necessarily hold exclusively UTC numbers of
second.

> But it's equally true, as Gary Miller and Martin have argued,
> that in practice people use time_t for all sorts of other things...
> but I think we can also agree that (some of the time, at least)
> this can lead to additional real confusion, precisely because it
> breaks the spec, precisely because doing so may clash with someone
> else's spec-based assumptions.

I don't think this breaks the spec, see above. IMO, time_t is just the
type of parameters used with time(), gmtime() and friends, its bit width
is implementation defined, but if you use it you are always safe to use
an appropriate data type with those functions.

> But the real tragedy is that UTC is the timescale that time_t is
> the *worst* at representing, precisely because time_t is a uniform
> count of seconds since an epoch, and UTC is nonuniform.  Anyone
> who tries to "fix" some time_t-using software to do UTC "properly"
> is doomed to failure.  At best they'll end up reinventing TAI.
> 
> To my mind, a pretty good litmus test for how good an alleged
> scheme for properly handling leap seconds actually is is to look
> at its data structure.  Can it represent :60 explicitly and
> unambiguously?  If not, it's probably a kludge that's never going
> to work perfectly.  (But, indeed, the near universality of time_t
> and related representations is one of the factors that makes
> "solving" the leap second problem almost impossible, and will
> likely help lead to the abandonment of leap seconds.)

I think a good solution would be to have a structure that contains a
time_t value plus at least one flag that indicates the leap second
status, or a field with TAI index. It would be even better to have such
additional information available with struct timespec, so an application
can tell if the time stamp is inside a leap second, or not.

> This message will get too long if I start discussing the data
> structures that *can* represent :60 explicitly and unambiguously.
> Some of them are:
> * struct timespec (using the nonnormalized trick described under
>   "Additional clocks" at https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html)
> * struct tm
> * the pair (days-since-epoch, seconds-within-day)
> * a time_t *plus* a well-defined bit disambiguating the two
>   instances of a repeated second across a leap second

If a timestamp has an associated status information available then it is
no problem for a library function like gmtime() or localtime() to set
the seconds field to 60 during a leap second.

We use a similar approach in the library functions we use for the
firmware of our PCI cards, etc.

On the other hand, if you normalize "60" seconds you get one more minute
which lets 59 increase to 60, and so on, so you will also get the
effective date/time twice. It's just a question how to interpret the
numbers.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy