[PATCH] timekeeping: Initialize TAI offset to 37 seconds

[PATCH] timekeeping: Initialize TAI offset to 37 seconds

[Miroslav Lichvar]

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

Cc: Richard Cochran <richardcochran@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
 kernel/time/timekeeping.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index dcf47f1ffdcf..e76e44b194da 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -34,6 +34,8 @@
 
 #define TK_UPDATE_ALL		(TK_CLEAR_NTP | TK_CLOCK_WAS_SET)
 
+#define TK_INITIAL_TAI_OFFSET	37
+
 enum timekeeping_adv_mode {
 	/* Update timekeeper when a tick has passed */
 	TK_ADV_TICK,
@@ -2091,6 +2093,8 @@ void __init timekeeping_init(void)
 
 	tk_set_wall_to_mono(tks, wall_to_mono);
 
+	__timekeeping_set_tai_offset(tks, TK_INITIAL_TAI_OFFSET);
+
 	/*
 	 * Use TK_UPDATE_ALL so the NTP layer picks up the clocksource's
 	 * cs_tick_adj via ntp_clear(). Clearing NTP here is otherwise
-- 
2.56.0

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

[David Woodhouse]

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

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

[John Stultz]

On Thu, Nov 5, 2026 at 5:53 AM Miroslav Lichvar <mlichvar@redhat.com> 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.

Should we also emit a warning if/when applications try to change it?

thanks
-john