[LEAPSECS] Time math libraries, UTC to TAI

[Steffen Nurpmeso]

Warner Losh <imp at bsdimp.com> wrote:
 |On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit <scs+ls at eskimo.com> wrote:
 |> Warner Losh wrote:
 |>> On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit <scs+ls at eskimo.com> wrote:
 |>>> 2. Have xtime keep TAI.  This has the advantage that it's not at
 |>>>    all wrong or kludgey to represent TAI as a simple count of
 |>>>    seconds since the epoch, which of course xtime already is.
 |>>
 |>> The problem here, not listed, is with external stuff. When I touch
 |>> a file, the time needs to be stored in UTC time so TAI needs to be
 |>> converted to UTC
  ...
 |But keeping the kernel time in TAI and reporting it in UTC still
 |doesn't solve the userland side of things because time goes backwards
 |across the leap second... If everything were in TAI and it was just a
 |conversion, then some math with time breaks.

Yes, the userland.  It currently is in blind flight and has to
take whatever the kernel delivers.  And it doesn't even know that
something has happened unless the kernel provides a CLOCK_TAI.  Of
course anything you have said on the list of incredible Eunuchs is
absolutely true, and you are an expert in this area, and many
programs, including anything i (am about to) maintain really don't
care.  But as a general thought i think it is true that what
i don't know won't hurt me.  For example if i would write
a calendar application, the only option i had to inform my user
about an upcoming leapsecond event would be to query the IERS
file, or, as a weak option, to iterate over the allowed times and
hope the local TZ package is up-to-date.

There is not even an easy way to detect time limits in the
standard set of time functions, for the MUA i maintain i just
recently added jdn-to-gregorian and way back functions in order to
deal exactly and even efficiently with integer overflow in (dates
of) test mail messages that were posted on the bugtracker of the
most famous text-UI MUA.  Not even that.  So please, i want my
longing for CLOCK_TAI to be understood as a synonym of the desire
for a better time and date interface on the portable C language
level.  So to say.  It is incomplete.

--steffen