[LEAPSECS] leap seconds in POSIX

[Brooks Harris]

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