Hal,
I see some good comments; did you get the answer you wanted? My take:
> Does anybody know of a good writeup of how to fix POSIX to know about
leap seconds
> and/or why POSIX hasn't done anything about it yet?
No write-up. No fix. It's not possible without breaking h/w, f/w, s/w,
and time_t.
----
Note this is not a POSIX issue per se. All POSIX did was rubber stamp
and formalize what various versions of UNIX did at the time. The method
of linear timekeeping where you pick an origin and count regular time
intervals was widely used in other systems of the era too: from
wristwatches to wall clocks, from astronomical time to telephone time,
from mainframes to minicomputers. They all fail to handle leap seconds.
If necessary, for a given application, you may be able to hack your way
around leap seconds. But it's not POSIX then.
One practical work-around is to recognize that the words UTC or POSIX or
time_t do not contain an accuracy specification. Thus you can weasel
your way out and claim "one second or worse" accuracy and simply gloss
over the existence of leap seconds.
However, this work-around fails if you are required to provide
sub-second accuracy. Then you're stuck providing true UTC, leap seconds
and all.
/tvb
On 1/27/2020 12:59 AM, Hal Murray wrote:
Does anybody know of a good writeup of how to fix POSIX to know about leap
seconds and/or why POSIX hasn't done anything about it yet?
I assume the basic idea would be something like switch the kernel to use TAI
rather than UTC and implement conversion in some library routines.
There is a discussion on the IETF ntp list with typical S/N for this topic.
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
