On 2020-02-01 9:39 AM, Brooks Harris wrote:
On 2020-01-30 7:02 AM, Tom Van Baak wrote:
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
I would add a couple observations.
You cannot fit 86401 pegs in 86400 holes.
I've come to recognize POSIX time as essentially the classic Gregorian
calendar algorithm without leap-second compensation. So the problem is
not just 'computer time', like POSIX time, but more broadly what civil
time is traditionally and practically taken to be by most people as
the calendar on the wall and time-of-day by the clock on the wall,
with 86400 seconds in each and every day.
UTC mandates introduction of leap-seconds in the YMDhms count sequence
as "YMD 23:59:60" (ignoring the unlikely disaster of a negative
leap-second). POSIX time_t is a zero-based uninterrupted incrementing
count of seconds *without leap-seconds* since it's so-called "The
Epoch", "1970-01-01 00:00:00". When represented as YMDhms by means of
POSIX gmtime() it results in the classic Gregorian calendar YMDhms
sequence, what POSIX calls "broken down time" as represented in POSIX
struct tm. The 86401th peg, the leap-second, goes missing. There are
only 86400 holes in POSIX time.
(As I understand it time_t is deprecated and replaced by struct
timespec in modern POSIX systems. This does not eliminate the
leap-second difficulty.)
Nearly all computer systems and applications operate the same way. For
example classic Windows time uses a "1601-01-01" origin in its struct
FILETIME and YMDhms representation in its struct SYSTEMTIME. It's
behavior is similar to POSIX time, that is, it is a representation of
classic Gregorian calendar without leap-second compensation. [But
watch out! The latest Windows systems will offer the option to use
leap-second compensated date and time. Systems so configured will
stray from classic Windows time and from POSIX time when the next
leap-second occurs. Fun will commence.]
The leap-second modification of the Gregorian calendar YMDhms counting
sequence presents an irreconcilable dilemma. I think most appropriate
term to describe the UTC v.s. computer time and civil time mismatch is
"incommensurate". You cannot map UTC into Gregorian without losing
something, and that something is the leap-second.
As Tom points out, the definition of the POSIX origin, "The Epoch", is
*intentionally* vague to accommodate systems that could not accurately
align to "1970-01-01 00:00:00". This date and time is said to be "UTC"
but this is misleading as it is not strictly UTC because A) the count
skips leap-seconds and B) UTC was not an integral second adjustment
until 1972-01-01 00:00:10 (TAI) = 1972-01-01 00:00:00 (UTC) (I like to
call this alignment point UTC1972), so the POSIX "the Epoch",
1972-01-01 00:00:00 (POSIX), sits in the never-never world before
UTC1972. As I understand it modern systems try to align "the Epoch" at
exactly 63072000s (730 86400s days) before UTC1972.
-Brooks
Apologies to Tom. I may have misunderstood or misrepresented his
meaning. Please delete "As Tom points out," from the above paragraph.
Sorry Tom.
-Brooks
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
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
