[PATCH] libc/time: Add CLOCK_TAI

[Brian Inglis]

On 2025-07-17 03:19, Corinna Vinschen wrote:
> [Moving this to cygwin-developers]
[Bounced - Subscribed]> 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).

One disadvantage of tzdb zic leapseconds is you have to sum the +/- and add a 
fudge factor of 10 to get the TAI offset, whereas leap-seconds.list last data 
line gives the current offset 37 directly, if the NTP timestamp is in the past.

> 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.

What scares people, if current DUT1 trends continue, we could need a *negative* 
leap second before then, ~7 years from now.

English common law legal systems in the Commonwealth, US, and some others all 
have a legal basis of mean solar time, so those national bodies have not, and 
mostly will not, agree to any change in legal timekeeping, to anything not 
substantially similar to current.

The previous time standards body, the ITU, which set the standards for radio 
broadcast dissemination of frequency, time, and leap seconds, appears to be 
substantially obsolete in that regard, as broadcast media is on the wane, 
frequency and time stations have been shut down, radio accuracy is only good 
enough to set clocks and watches, are not available at times due to  maintenance 
(see UK NPL Anthorn MSF next 3 weeks 08-18BST), and modern digital broadcasts 
have large, unpredictable processing delays making them to inaccurate for any 
time service.

Brexit may have had that benefit for the EU, if it decides it can agree on a 
different legal time metric, but substantial disagreement within any Union, or a 
sufficient number of national bodies, may continue to block international orgs 
from making incompatible changes.

> 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".

Unlike leap-seconds.list, and like MS date/time/zone approximations, without the 
list of leap-seconds, accurate past time zone and TAI values are not available, 
whereas tzdata-right provides interesting values like:

$ for y in {1972..2025}; do for md in 06-30 12-31; do \
   ls=`TZ=right/UTC date -ud "$y-$md 23:59:60" 2> /dev/null` && echo $ls; \
   done; done
1972 Jun 30 Fri 23:59:60
1972 Dec 31 Sun 23:59:60
1973 Dec 31 Mon 23:59:60
1974 Dec 31 Tue 23:59:60
1975 Dec 31 Wed 23:59:60
1976 Dec 31 Fri 23:59:60
1977 Dec 31 Sat 23:59:60
1978 Dec 31 Sun 23:59:60
1979 Dec 31 Mon 23:59:60
1981 Jun 30 Tue 23:59:60
1982 Jun 30 Wed 23:59:60
1983 Jun 30 Thu 23:59:60
1985 Jun 30 Sun 23:59:60
1987 Dec 31 Thu 23:59:60
1989 Dec 31 Sun 23:59:60
1990 Dec 31 Mon 23:59:60
1992 Jun 30 Tue 23:59:60
1993 Jun 30 Wed 23:59:60
1994 Jun 30 Thu 23:59:60
1995 Dec 31 Sun 23:59:60
1997 Jun 30 Mon 23:59:60
1998 Dec 31 Thu 23:59:60
2005 Dec 31 Sat 23:59:60
2008 Dec 31 Wed 23:59:60
2012 Jun 30 Sat 23:59:60
2015 Jun 30 Tue 23:59:60
2016 Dec 31 Sat 23:59:60

which is another source of leap second info which may be used by chrony with 
chrony.conf "leapsectz right/UTC".

> 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.

Basic leap-seconds.list is not much more complex - I use it in a bunch of time 
conversion bash scripts to handle pending leap seconds in time scale conversions 
for future dates/times.

Could also just add the reg keys although the LeapSeconds entry looks to be 
another of MS opaque REG_BINARY values!

Wonder if Windows could handle adding all the historical leap seconds?

$ for t in `tz-right-leap-seconds.sh %FT%T`; do \
	w32tm /leapseconds /add:+${t%:60}:59 /force; done
Error parsing the given datetime string: +1972-06-30T23:59:59
Please make sure it is in the format [+-]YYYY-MM-ddThh:mm and represents a valid 
datetime.
Examples: +2018-12-31T23:59, -2019-06-30T23:59, +2019-12-31T23:59:59
Failed to add leap second either due to input parsing failure or because there 
are identical or newer leap second(s) in the settings.
...
Error parsing the given datetime string: +2016-12-31T23:59:59
Please make sure it is in the format [+-]YYYY-MM-ddThh:mm and represents a valid 
datetime.
Examples: +2018-12-31T23:59, -2019-06-30T23:59, +2019-12-31T23:59:59
Failed to add leap second either due to input parsing failure or because there 
are identical or newer leap second(s) in the settings.

Nope - with or without trailing :59s - really the time is redundant!

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

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

Also:

https://techcommunity.microsoft.com/blog/networkingblog/leap-seconds-for-the-it- 
pro-what-you-need-to-know/339811

-- 
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