Re: [PATCH] libc/time: Add CLOCK_TAI
Corinna Vinschen via Newlib <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
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: > > $ ntpq -c'rv 0 tai' > tai=37 > $ ntpq -c'rv 0 tai,leapsec,expire' > tai=37, leapsec=201701010000, expire=202606280000 > > assuming you keep it updated from IERS, NIST, and/or USNO upstreams. > > Or install tzdata-right to get leapsecond compensated timezones at TAI-10s: > > $ ntptime.sh; TZ=right/UTC date +%c%z; date -u +%c%z; TZ=right/$TZ date > +%c%z; date +%c%z > 2025 Jul 14 Mon 20:15:33+0000 JD 2460871.344132 MJD 60870.844132 ToD 72933 > NTP 3961512933 Unix 1752524133 TAI-UTC 37 TAI-GPS 19 GPS-UTC 18 > GPS We 2375 Cy 2 Wn 327 Wa 71 ToW 159351 DoW 1 ToD 72951 > 2025 Jul 14 Mon 20:15:06+0000 > 2025 Jul 14 Mon 20:15:33+0000 > 2025 Jul 14 Mon 14:15:06-0600 > 2025 Jul 14 Mon 14:15:33-0600 > > These are updated with every IERS Bulletin C leapsecond announcement and > data update, made available in the next tzdata release. I read up on leap secs and TAI yesterday, and it seems Linux is not doing as lot by itself (i.e., the kernel). Also, leap secs are pretty static, especially since 2017. We had no leap sec since that time anymore, so we're on a 37 sec shift for ~8 years. We need some way to handle that without extra packages. Ideally this is between the Cygwin DLL and the OS with no extra layer between them. Unfortunately I didn't find a Windows API to ask the OS for the current leap secs offset. 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. So, yeah, we can just add CLOCK_TAI and we add that functionality to the Cygwin DLL for the 3.7 release cycle. Shouldn't be too much work. So, Sebastian, just go ahead defining CLOCK_TAI. A __BSD_VISIBLE guard seems like a good idea. Maybe adding a `|| _GNU_VISIBLE' for readability, even if that's redundant... Thanks, Corinna