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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.