[PATCH] libc/time: Add CLOCK_TAI

[Corinna Vinschen]

[Moving this to cygwin-developers]

On Jul 16 14:52, Brian Inglis wrote:
> On 2025-07-16 13:04, Corinna Vinschen wrote:
> > On Jul 16 11:39, Brian Inglis wrote:
> > > On 2025-07-16 04:38, Corinna Vinschen wrote:
> > > > 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/?
> > 
> > No. Please just add it to your next tzdata package at the same
> > spot it's on Fedora, i.e. /usr/share/zoneinfo/leap-seconds.list.
> 
> That is a extremely non-standard location for *any* access to
> leap-seconds.list from any system, and like anything else in tzdata, it
> could change or be dropped: it should at least be symlinked from /etc/?

You can do that, but the file should be where it is on Fedora as well.

> RH chrony requires leapseclist:
> 
> 	https://chrony-project.org/doc/4.7/chrony.conf.html#leapseclist
> 
> 	leapseclist /usr/share/zoneinfo/leap-seconds.list

In our case it's inside the DLL.  Right now the code uses
/usr/share/zoneinfo/leapseconds, see
https://sourceware.org/cgit/newlib-cygwin/commit/?id=2abb929f0ad2

It's actually a bit of a bummer either way.  Just to find out the
current leap second offset, we have to read a file of 80 lines
(leapseconds) or even 120 lines (leap-seconds.list).  There's a good
chance we'll never have another leap second, given the latest leap sec
was 2017, and leap secs will be deprecated entirely in 2035.

So I'm mulling over this anyway:

- Isn't it sufficient to hardcode the leap secs to 37, as in the case we
  don't have a leap secs file?  If leap secs change, just update the DLL?

- Wouldn't it actually be more helpful to keep a dead-simple mechanism
  to just read a number from an /etc/leapsecs file and *only* provide
  the file after IERS bumped the leap secs *and* we can't provide a new
  DLL quickly enough for some reason?

In the end, maybe Windows actually comes to the rescue.  Leap seconds
support has been added in 2018 to Windows 10(*).  There's a new registry
key HKLM\SYSTEM\CurrentControlSet\Control\LeapSecondInformation with a
value "LeapSeconds".  So, how is that supposed to work?(**)

Apparently the OS has the leap secs timestamps hardcoded builtin (so
we're @ 37 secs by default).  The "LeapSeconds" entry is empty.
However, you can add timestamps to this value:

  w32tm /leapseconds /add:+2021-11-30T23:59:59 /force

This timestamp gets added to the "LeapSeconds" registry value.  Rinse and
repeat.

So I think the DLL should actually read and evaluate that registry key
in the first place.  37 secs, plus the entries in "LeapSeconds".

But, what about pre-2018 OSes, like Windows 8.1 and Windows 10 <= 1709?
For those, we can think of maintaining that very simple /etc/leapsecs
file and be done with it.

I'm planning to rework this in the next few days.

  
Corinna

(*) https://techcommunity.microsoft.com/blog/networkingblog/leap-seconds-for-the-appdev-what-you-should-know/339813
(**) https://github.com/microsoft/STL/discussions/1624