[Ksummit-discuss] Leap second handling
arnd at arndb.de
Tue Dec 15 12:12:03 UTC 2015
On Tuesday 15 December 2015 11:33:58 David Howells wrote:
> I know it's a bit late for the KS, but should we alter the interpretation of
> the time-as-seconds-since-1970 in the kernel to include leap seconds?
> The reason I ask is that we have to deal with X.509 certificates in the kernel,
> and the certificate can have dates encoded using GeneralizedTime ASN.1 objects.
> These are formatted as per ISO 8601. ISO 8601 encodes leap seconds as hh:mm:60
> - so it's possible that I can see this in cert I have to deal with, and as such
> I must permit it. I turn the date and time components into a time64_t with
> mktime64() - but that doesn't know about leap seconds, however.
Adding John Stultz to Cc explicitly, he probably knows best about those things.
> So the question is how to deal with it. I can see three obvious ways:
> (1) Treat it the same as hh:mm:59.
> (2) Treat it the same as hh:mm+1:00, rolling over the carry through to the
> year if necessary.
> (3) Assign specific time_t values to leap seconds in mktime64(). There's a
> table of them here:
> It wouldn't be hard to do within just the kernel, but this would put the
> kernel at odds with userspace to the tune of nearly half a minute at the
> current time. It might be sufficient to just fix the libc's in userspace
> - but you can bet there's someone somewhere who checks that seconds
> doesn't exceed 59.
> The kernel would also need to tell libc whether or not the time value it
> gets includes leap seconds.
> Any thoughts?
The kernel supports CLOCK_TAI as a timebase. While I think some operating systems
use this as the default clock, we don't do that, and I assume we don't want
to change this.
ktime_get_clocktai() will return the time in this format, and the timekeeper
stores the offset between boottime and TAI internally, and updates it whenever
a leap second happens, so if you set a timer in CLOCK_TAI, it will expire at
the right moment.
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
More information about the Ksummit-discuss