Re: [PATCH] timekeeping: Initialize TAI offset to 37 seconds

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

On Thu, 2026-11-05 at 14:53 +0100, Miroslav Lichvar wrote:
> With Resolution 5 of the 28th CGPM (continuous UTC becoming effective on
> 20 May 2027) [1] and no leap second announced for the last possible
> date at the end of the year 2026 [2], no more leap seconds or other
> leaps in UTC are expected for at least a few hundred years. The TAI-UTC
> offset can be assumed now to be constant (37 seconds).
> 
> Set the offset in the timekeeping initialization to the expected value
> to not require it to be set in user space via ADJ_TAI. It can still be
> changed, and leap seconds can still be set, but nothing should be
> expected to do that anymore. Existing applications are expected to
> either set the offset to the same value, or not touch it at all if they
> see it is not zero.
> 
> [1] https://www.bipm.org/en/cgpm-2026/resolution-5
> [2] https://datacenter.iers.org/data/16/bulletinc-072.txt

For the kernel patch,

Acked-by: David Woodhouse <dwmw@amazon.co.uk>

Although I don't want that to be taken as any kind of endorsement of
the rampant horseshit that is this statement from your [1]:

|recognizing that
|
|    industrial users and the synchronization needs of national critical
|    infrastructures, for example transportation, energy distribution,
|    telecommunication, and space projects require UTC to be continuous
|    without any future adjustment, 

... or of the idea that doing a *larger* jump, much *less* frequently,
is a better idea. They should have just inserted either a positive or
negative leap second at *every* opportunity instead, to help make sure
that bugs are caught.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]