Warner wrote: > On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit <[email protected]> wrote: > > Warner Losh wrote: > >> It then becomes an interesting question: do you have to back convert > >> form UTC to TAI when doing a stat on a file in this scheme? > > > > No, not at all. The timestamp in the inode on disk was stored in > > UTC, as it always has been. > > Right, and is the time_t in the st_atime, st_mtime and st_ctime fields > reported as UTC or TAI?
All times are stored in the inode in UTC, and (per Posix) are reported by stat() in UTC. I'm really not sure why you're even suggesting the possibility of converting to/from TAI here. (I've seen occasional suggestions of storing TAI in the inode, but it's clearly a terrible idea, that would impose ruinous conversion requirements and introduce nightmarish compatibility conflicts.) > 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... Keeping kernel time in TAI is a separate question from what clock_gettime(CLOCK_REALTIME) reports, which is of course a separate question from what clock_gettime(CLOCK_UTC) reports. I mentioned the possibility of keeping TAI in the kernel as one point along a spectrum of options in support of being able to accurately report CLOCK_UTC at all. By itself it clearly doesn't do anything to solve the problem of mapping UTC onto time_t. But as a separate piece of the puzzle I'm also smearing CLOCK_REALTIME across leap seconds (that is, in the process of deriving CLOCK_REALTIME from whatever modified internal clock I'm using) so that it never jumps or runs backwards. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
