Brooks Harris wrote: > It seems to me infeasible to alter the basic behavior of time_t > because it effects every aspect of the operating system,
Absolutely. Posix time_t is untouchable, and here to stay. > POSIX time and 86400-second-day systems (including Windows time) will > never exactly match UTC at the Leap Second and we'll have to live > with that partial inaccuracy for a long time. Right. (But I don't know if people will find the inevitable discrepancies between time_t and "Time2" acceptable.) > But a second, parallel, time system (call it POSIX Time2) could > implement a fixed-epoch timer (call it time2_t) and a > Leap-Second-accurate API that would yield YMDhms representation > including 23:59:60, call them, for examples, gmtime2() and mktime2(). That's essentially what clock_gettime(CLOCK_UTC) gets you. A struct timespec fetched with clock_gettime(CLOCK_UTC) is your "POSIX Time2". I have implemented gmtime_ts_r() and mktime_ts() which operate on struct timespec, and do the right thing with :60. > With that, those applications that needed it could use the POSIX Time2 > API, and everybody else would be none the wiser. It would also define > the mapping between legacy POSIX and the UTC-accurate POSIX Time2. That's exactly my intent, and I have it all working on my test system today. Just one or two more bugfixes and I should be ready to post it! (I've been saying for the past several months.) > Eventually, maybe the file system timestamps could be augmented with > flags to mark Leap Second instances and local time parameters. I'm not ready to think about the filesystem yet (beyond thinking that leapsecond-aware filesystem timestamps don't seem nearly as important). First I've got to get non-UTC timers (i.e., almost all of them) working properly in the face of smeared time, and that's going to be plenty hard, and then some. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
