[LEAPSECS] leap seconds in POSIX

[Brooks Harris]

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

>
>
> 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
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>