On January 6, 2017 at 5:50 PM Brooks Harris <bro...@edlmax.com> wrote:
On 2017-01-05 09:33 PM, Steve Summit wrote:
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.)
That's been at the heart of the "eliminate Leap Seconds debate", right?
Two camps, basically. But given both UTC with Leap Seconds and Gregorian
as inevitable conventional circumstances its no longer a question of
acceptable or not. It is what it is, so lets agree how best to support
the two with the least inaccuracy, least complexity, and least
disruption to existing systems. It can't be perfect; the two just do
not, and will not, match. There's not enough holes in Gregarian to
accommodate the Leap Second pegs.
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.
Ah good.
What source are you using for the Leap Seconds? Tz Database?
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.)
Its a harder problem than it appears, as those of us who've got our
fingers dirty with the implementation details can attest. Going at it
directly in the OS takes guts :-)
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).
I think the challenge inevitably arrives at the file system(s), so a
comprehensive plan should anticipate how that could eventually be
accomplished. This is related to Harlan's "General Timestamp API"
project, I think.
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.
Yes, this looks like it could create severe brain damage.
-Brooks
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
