Martin Burnicki wrote: > Steve Summit wrote (offlist): > > In some ways I agree that running the kernel on TAI would be far > > preferable. I've shied away from it so as to be able to answer > > the critics who are always worrying about disconnected systems > > that might not have a source of TAI-UTC at boot time, or at all. > > If your system time is disciplined via NTP then currently the TAI/UTC > offset may not be available since the default NTP protocol doesn't > provide it. > > As said earlier, you can use tzdist, or DNS, or a future NTP extension > field to pass down the UTC/TAI offset to clients.
Right. I'm considering all of these. > If the kernel runs on TAI, but the TAI time isn't synchronized anyway, > and the TAI offset is 0, then the UTC time stored in inodes matches TAI > time on this system, but who cares? Right. > BTW, AFAICS current Linux kernels increment the TAI offset when they > insert a leap second. I wonder if that is appropriate. Uh oh, I think I see where you're going with this... > Initially, if the kernel's TAI offset has not been set then it is 0, so > callers of adjtimex() can see that the offset has not yet been set. > > However, after a leap second the kernel increases the TAI offset to 1, > which *might* suggest to the unexperienced user that the TAI offset is > valid. Definitely. This is a very good point. > So I think the kernel should increment the TAI offset value only if > it has been set before, i.e. if it isn't 0 I quite agree. I hadn't thought about this case. I shall have to tweak my code. Thanks. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
