[LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

On Thu, 05 Mar 2015 14:55:58 +0100, Martin Burnicki wrote:
> Joseph Gwinn wrote:
>> On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:
>>> Now in 4.2.8 the leap second code has been reworked and cleaned up,
>>> and a very quick look at the source code seems to indicate that this
>>> might work again. At least there's code which passes the announcement
>>> flag to the kernel, if kernel support is enabled.
>>> 
>>> I think I'll give it a try soon. I'd expect that a negative leap
>>> second might work if an appropriate announcement is received from a
>>> refclock or upstream NTP server, but it will be interesting to find
>>> out if this works with a NIST-style leap second file where the TAI
>>> offset decreases at a given date.
>> 
>> Hell - lots of code can't handle a positive leap second, so what hope
>> is there?
> 
> Should we abandon everything which can't easily be handled, or where 
> developers don't work thoroughly?

Nahh.  I'm just saying don't get your hopes up.


>> Right now, GPS System Time is the best solution.  In ten years, I bet
>> the answer will be TAI.
> 
> Agreed.
> 
> And we might already start to think about how to get this right in 
> mixed environments, e.g. using the NTF's General timestamp API, or 
> find a way to determine if the kernel time is UTC, or TAI.

Yes.  My experience is that it can be hard to get the time community to 
agree on an approach, especially if the community must convince 
non-time communities (like POSIX) to implement something perfect but 
very complex, especially if it doesn't solve a problem important to 
non-time folk.

Joe Gwinn