Re: [PATCH] libc/time: Add CLOCK_TAI

On 2025-07-16 04:38, Corinna Vinschen wrote:
> On Jul 16 11:18, Corinna Vinschen via Newlib wrote:
>> On Jul 15 15:01, brian.inglis--- via Newlib wrote:
>>> On 2025-07-15 02:43, Corinna Vinschen via Newlib wrote:
>>>> On Jul 14 14:38, Brian Inglis via Newlib wrote:
>>>>> On 2025-07-14 09:45, Corinna Vinschen via Newlib wrote:
>>>>>> On Jul 11 06:35, Sebastian Huber wrote:
>>>>>>> FreeBSD also provides this clock identifier, maybe it should be
>>>>>>> #if __BSD_VISIBLE
>>>>>>> #define CLOCK_TAI		(11)
>>>>>>> #endif
>>>>>>> ?
>>>>>
>>>>>> Probably, but I seriously wonder how to implement CLOCK_TAI on Cygwin.
>>>>>
>>>>>> IIUC, if you don't do anything special, the CLOCK_REALTIME and CLOCK_TAI
>>>>>> return the same value, because the leap second is set to 0 at kernel
>>>>>> startup.  Maybe that's enough...
>>>>>
>>>>> If you are running an NTP server you just have to ask for the system variable:
>>>>> [...]
>>>> What we could do is to define CLOCK_TAI as CLOCK_REALTIME + 37 in the DLL
>>>> for the time being, and the DLL could check if a file "/etc/leapsecs"
>>>> exists and read it to compensate for new leap secs.  We can add such a
>>>> file to the distro when a new leap sec has been defined.
>>>
>>> It may be better to just use the standard approach and standard file name
>>> which is /etc/leap-seconds.list, often symlinked from /etc/ntp/ which may
>>> itself be symlinked from /var/lib/ntp/.
>>
>> Actually, yesterday I hacked some POC code in my local Cygwin sandbox
>> using the file /usr/share/zoneinfo/leapseconds from tzdata.  If the file
>> isn't present, the DLL uses the current leap secs offset of 37 secs.
>> Seems to work nicely.
>>
>> So I'm looking forward to Sebastian adding the CLOCK_TAI macro to time.h.

Please do not base anything on tzdata leapseconds file, as that is really an 
internal implementation detail for zic in tzdata, generated by a tzdb awk script 
leapseconds.awk from leap-seconds.list.
That is a hack Paul came up with to avoid using leap-seconds.list directly for 
whatever reason, and may change or disappear if anything changes in zic, tzdata, 
or leap seconds, or his or another maintainer's approach.
Downstream compatibility is rarely an upstream concern; it is the responsibility 
of the downstream packagers to their users; why there has been a compatibility 
fork; and the instability could be why there have only been a few experimental 
tzdist servers, intended to distribute online updates of any releases globally.
To my mind, it should have been implemented internally within zic! ;^>

> I pushed Sebastians patch at his request.
> 
> Btw, Brian, the Fedora tzdata package contains not only the file
> /usr/share/zoneinfo/leapseconds, but additionally the original file
> /usr/share/zoneinfo/leap-seconds.list.
> 
> Can you please add it to your Cygwin tzdata package as well?

They are both included in upstream tzdata.
I can push out a release that packages the leap-seconds.list and makes it 
available from /etc/leap-seconds.list -> /etc/ntp/ -> /var/lib/ntp/?

Those paths were derived from a combo of BSD, Debian, Fedora, OpenSuSE setups 
and scripts, as the upstream leap-seconds.list are FTP and local symlinks to 
original files leap-seconds.########## where ########## is the NTP timestamp of 
the file creation per the NTP crypto file spec:

$ TZ=UTC ls -Gg leap-seconds.??????????
-r--r--r-- 1  9854 Jan 11  2012 leap-seconds.3535228800
-r--r--r-- 1 10381 Jan  5  2015 leap-seconds.3629404800
-r--r--r-- 1  4928 Apr  3  2015 leap-seconds.3637008000
-r--r--r-- 1  4928 Jul  7  2015 leap-seconds.3645216000
-r--r--r-- 1 10378 Jul 11  2015 leap-seconds.3645639840
-r--r--r-- 1  4927 Sep 16  2015 leap-seconds.3651350400
-r--r--r-- 1  4928 Jan 11  2016 leap-seconds.3661459200
-r--r--r-- 1  4928 Jan 13  2016 leap-seconds.3661632000
-r--r--r-- 1  4920 Jul  6  2016 leap-seconds.3676752000
-r--r--r-- 1 10404 Jul  8  2016 leap-seconds.3676924800
-r--r--r-- 1  4921 Jan  9  2017 leap-seconds.3692908800
-r--r--r-- 1  4925 Jan 19  2017 leap-seconds.3693772800
-r--r--r-- 1  8795 Apr 18  2017 leap-seconds.3701462400
-r--r--r-- 1  4921 Jul  7  2017 leap-seconds.3708374400
-r--r--r-- 1  4923 Jan  9  2018 leap-seconds.3724483581
-r--r--r-- 1  8788 Jan 10  2018 leap-seconds.3724531200
-r--r--r-- 1  4921 Jul  5  2018 leap-seconds.3739787886
-r--r--r-- 1  8788 Oct 12  2018 leap-seconds.3748291200
-r--r--r-- 1  4925 Jan  7  2019 leap-seconds.3755859566
-r--r--r-- 1  8789 Jan 28  2019 leap-seconds.3757622400
-r--r--r-- 1  4953 Jan  7  2020 leap-seconds.3787382231
-r--r--r-- 1  4949 Jul  7  2020 leap-seconds.3803144275
-r--r--r-- 1  4949 Jul  5  2021 leap-seconds.3834432000
-r--r--r-- 1  4953 Jan  5  2022 leap-seconds.3850377469
-r--r--r-- 1  4949 Jul  5  2022 leap-seconds.3865995417
-r--r--r-- 1  4949 Jul  4  2023 leap-seconds.3897417600
-r--r--r-- 1  5069 Jan  8  2024 leap-seconds.3913697179
-r--r--r-- 1  5064 Jul  4  2024 leap-seconds.3929093563
-r--r--r-- 1  5069 Jan  7  2025 leap-seconds.3945196800
-r--r--r-- 2  5065 Jul  7 00:00 leap-seconds.3960835200

Updated files are created within the first two work weeks of each half year, and 
expire on the 28th of the last month of the half year in which the next Bulletin 
C announcement should be made, and the next update created, normally, allowing 
for nearly six months slack in making the next announcement, and dealing with 
any issues in the released files, which in the past have included update and 
expiry dates, timestamps, and hashes.

Originally leap-seconds files were distributed by NTP servers to their clients, 
but lack of servers and bandwidth with a surfeit of clients and requests 
eliminated that approach, later FTP servers stopped being provided by NTP 
servers, and servers supporting FTP generally were dropped, reducing the 
upstreams to just IERS, NIST, and USNO (when the .mil firewalls allow!)

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry