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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
