Date: Fri, 07 Mar 2025 20:29:08 +1100
From: matthew green <m...@eterna23.net>
Message-ID: <23937.1741339...@splode.eterna23.net>
| only true as long as "arbitrary" can fit into a 32-bit signed
| count in ticks. ie, 248 days with HZ=100, etc.
That's only the case for the internal low level timeout
routines, it is trivial for the kernel to build a loop
around that, and sleep for however long is needed.
That's how nanosleep(2) works, it can sleep, from one call,
for thousands of years if needed (provided the system stays
running that long). What HZ happens to be is irrelevant
(except to the precision available).
It is till not a good idea for the kernel to attempt anything
related to dealing with civil time - that's just too
unpredictable. Even something which should be simple,
like a week (months are far too complex) like doing something
every Monday (or pick a day), get complex in situations
like happened near the 1999-2000 transition (not really the
end of "the" millenium, "a" milllenium, sure, but every new
second is one of those - but enough irrelevant hobby horse)
when some small pacific island nations deleted a day, by
moving from just east of the international date line, to
just west, so they could be "first into the new millenium"
(hence my rant above) leading to a week which had just 6
days - and if any of them later switched back, which I no
longer remember, there would have been an 8 day week then.
Deal with civil time entirely in application code, the kernel
can handle seconds (even, kind of, stretchy POSIX seconds)
and fractions thereof, anything more complex should not be
in the kernel.
And yes, those kinds of events are very rare - that just makes
them even more to be avoided, as things can seem to be working
perfectly for years, or decades, then something happens, and
no-one even considers that the code in question, probably long
forgotten, can't handle that new "something".
kre
