> On May 21, 2015, at 7:49 AM, Poul-Henning Kamp <[email protected]> wrote: > > -------- > In message <[email protected]>, Steve Allen writes: > >> POSIX does not want to know geophysics, nor astrometry, nor politics. >> POSIX does not care what is meant by "day". >> POSIX wants someone else to decide what "day" means, and for all those >> other details to be handled outside the kernel in the libraries and >> applications. > > POSIX is not just a kernel API, it *also* defines the functions for > deciding what "day" means and all that.
POSIX has decided that a day is 86400 seconds. Thus you can’t implement days with leap seconds with SI seconds. And you can’t have a system that’s synchronized to UTC if you smear seconds or ‘drop’ that second. The down stream effects are a bunch of bad choices, which bad choice you make depends heavily on the application. Some (maybe most) second smearing is good. Others, where stable elapsed time matters a lot, smeared seconds are a disaster, but dropping a second is also bad. Having multiple choices here leads to poor quality of implementation of leap seconds. To do things moderately close to ‘right’ you have to invent your own thing, and then translate your ‘right’ thing into the imperfect POSIX thing and accept those folks that use purely POSIX interfaces can never have the whole story and will have some aspect of their time keeping disrupted around leap second events. The real problem here is that POSIX defines time passing in such an abstract way that you can’t use UTC to realize it without something giving. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
