Warner Losh <[email protected]> wrote: |On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit <[email protected]> wrote: |> Warner Losh wrote: |>> On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit <[email protected]> wrote: |>>> 2. Have xtime keep TAI. This has the advantage that it's not at |>>> all wrong or kludgey to represent TAI as a simple count of |>>> seconds since the epoch, which of course xtime already is. |>> |>> The problem here, not listed, is with external stuff. When I touch |>> a file, the time needs to be stored in UTC time so TAI needs to be |>> converted to UTC ... |But keeping the kernel time in TAI and reporting it in UTC still |doesn't solve the userland side of things because time goes backwards |across the leap second... If everything were in TAI and it was just a |conversion, then some math with time breaks.
Yes, the userland. It currently is in blind flight and has to take whatever the kernel delivers. And it doesn't even know that something has happened unless the kernel provides a CLOCK_TAI. Of course anything you have said on the list of incredible Eunuchs is absolutely true, and you are an expert in this area, and many programs, including anything i (am about to) maintain really don't care. But as a general thought i think it is true that what i don't know won't hurt me. For example if i would write a calendar application, the only option i had to inform my user about an upcoming leapsecond event would be to query the IERS file, or, as a weak option, to iterate over the allowed times and hope the local TZ package is up-to-date. There is not even an easy way to detect time limits in the standard set of time functions, for the MUA i maintain i just recently added jdn-to-gregorian and way back functions in order to deal exactly and even efficiently with integer overflow in (dates of) test mail messages that were posted on the bugtracker of the most famous text-UI MUA. Not even that. So please, i want my longing for CLOCK_TAI to be understood as a synonym of the desire for a better time and date interface on the portable C language level. So to say. It is incomplete. --steffen _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
