HEADSUP: Re: [PATCH] libc/time: Add CLOCK_TAI

[Corinna Vinschen]

On Jul 17 11:19, Corinna Vinschen wrote:
> 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".

If you're playing around with this, adding leapsecs to this registry
value, and if your machine is a domain member machine, please be

VERY, VERY

careful!

For testing I added and removed leapsecs multiple times to and from the
registry.

In the end I had two leapsec timestamps, one in the past, and one in the
future.  The one in the past obviously created a leapsecs offset of 38
second compared to realtime, rather than the correct 37 secs, as the OS
sees it.

At this point, w32tm told me there's now an inconsistency between
runtime values and registry values and I should reboot... which I did.

After the machine came up again, I couldn't login anymore.  "Password
incorrect".  Thast was independent of the account being a local machine
account or a domain account.

It was also impossible to access the machine's registry from remote.

So the extra leapsec in the registry led to a timeshift between the
domain and the member machine, which was fatal for the secure
connection, apparently.

Fortunately I always have a backup, so I restored the machine from my
nightly backup and it's working again.

However, I thought a warning might be in order...


Corinna