From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B2D2FCA for ; Wed, 16 Dec 2015 05:12:57 +0000 (UTC) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BEA4910D for ; Wed, 16 Dec 2015 05:12:56 +0000 (UTC) Received: by mail-qk0-f170.google.com with SMTP id t125so48273148qkh.3 for ; Tue, 15 Dec 2015 21:12:56 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20151215141518.GE8574@piout.net> References: <10141.1450179238@warthog.procyon.org.uk> <2151085.9YAhiz9GYL@wuerfel> <20151215141518.GE8574@piout.net> Date: Tue, 15 Dec 2015 21:12:55 -0800 Message-ID: From: John Stultz To: Alexandre Belloni Content-Type: multipart/alternative; boundary=001a114920c67fa9000526fcf543 Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] Leap second handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --001a114920c67fa9000526fcf543 Content-Type: text/plain; charset=UTF-8 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 --001a114920c67fa9000526fcf543 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 15, 2015 at 6:15 AM, Alexandre Belloni <alexand= re.belloni@free-electrons.com> wrote:
On 15/12/2015 at 13:12:03 +0100, Arnd Ber= gmann 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 th= e
> harder questions to solve first if you want to handle the X.509 certif= icates
> right, before we get to the question of what happens for dates *on* th= e
> leap second.
>

My point of view is that we shouldn't do anything in the ke= rnel 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 l= eapseconds. So we repeat the leap-second, and for those that care you can c= heck the adjtimex timestate to see if the TIME_OOP flag is set to detect le= ap-seconds in progress.

So as long as there are le= apseconds =C2=A0(and with the most recent discussion on abolition not succe= eding), we're going to have to keep the existing behavior.
As for how to treat the certs, you're option #1 "Trea= t it as hh:mm:59" is probably the closest to what the kernel does, sin= ce it repeats the 59th second on the leapsecond. =C2=A0

Arnd' suggestion of encoding it into TAI is also something to con= sider as it is close to your suggestion, as it basically doesn't have a= ny 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 UT= C 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
--001a114920c67fa9000526fcf543--