[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLVB35cmoff6HLHe8cUne2P8RTQCAGGcRiQd_bP5=qvpZw@mail.gmail.com>
Date: Fri, 5 Jun 2015 10:28:54 -0700
From: John Stultz <john.stultz@...aro.org>
To: Richard Cochran <richardcochran@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
Prarit Bhargava <prarit@...hat.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Jan Kara <jack@...e.cz>, Jiri Bohac <jbohac@...e.cz>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Shuah Khan <shuahkh@....samsung.com>
Subject: Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths
On Fri, Jun 5, 2015 at 7:12 AM, Richard Cochran
<richardcochran@...il.com> wrote:
> On Fri, Jun 05, 2015 at 11:10:08AM +0200, Peter Zijlstra wrote:
>> Firstly I would strongly suggest such applications not use UTC because
>> of this, I think TAI was invented for just this reason.
>
> So I wonder whether the bug in the original post affects TAI timers as
> well...
No, I don't believe so. The TAI timeline doesn't have a
discontinuity(ie: each second is properly represented over a
leapsecond), so it wouldn't have the same issue with the specifics of
when that discontinuity is applied. Our TAI adjustment is done
atomically with the leap adjustment, so late or not it shouldn't have
problematic behavior.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists