On Tue, Dec 15, 2015 at 6:15 AM, Alexandre Belloni <
alexandre.belloni@free-electrons.com> wrote:

> On 15/12/2015 at 13:12:03 +0100, Arnd Bergmann wrote :
> > What I think we don't do at all in the kernel is to keep track of past
> (or
> > even future) leap seconds, so if you need to encode a date in the past,
> > the kernel has no idea what the difference between UTC and TAI was at the
> > time, and if you encode a time in the future, you don't know if we will
> > insert a leap second before you get to that time. I think these are the
> > harder questions to solve first if you want to handle the X.509
> certificates
> > right, before we get to the question of what happens for dates *on* the
> > leap second.
> >
>
> My point of view is that we shouldn't do anything in the kernel and
> instead handle that with proper TZ files (see leapseconds in
> tzdata2015g). You can then handle your own leapseconds epoch and add
> future leapseconds without having to update your kernel.
>

So while these approaches are attractive, I think we're kind of stuck with
the current behavior. Posix times don't include leapseconds. So we repeat
the leap-second, and for those that care you can check the adjtimex
timestate to see if the TIME_OOP flag is set to detect leap-seconds in
progress.

So as long as there are leapseconds  (and with the most recent discussion
on abolition not succeeding), we're going to have to keep the existing
behavior.

As for how to treat the certs, you're option #1 "Treat it as hh:mm:59" is
probably the closest to what the kernel does, since it repeats the 59th
second on the leapsecond.

Arnd' suggestion of encoding it into TAI is also something to consider as
it is close to your suggestion, as it basically doesn't have any
leapseconds (just a number of seconds since 1970) but requires you have a
table of leap-seconds to properly translate between TAI time values to UTC
and back. The other problem with TAI is that while the kernel supports it,
not many systems are configured to properly initialize it, so its likely to
match UTC most of the time. But if you're only using TAI internally in your
app, and translating out to UTC as needed, that might not matter.

thanks
-john