On Tue, Feb 18, 2025, at 14:30, Alexandre Belloni wrote: > On 18/02/2025 13:45:56+0100, Einar Jón wrote: >> Hello again >> >> On second thought, removing is too general. >> But it's still very much broken. Is there any reason why this was not >> merged? >> https://lore.kernel.org/all/c5e8ab50-aacb-4651-8893-a6dd9edcd155@xxxxxxxxxxxxxxxx/T/ >> >> Any thoughts on how this should be handled? > > The first step is to convince Lennart that mandating RTC_HCTOSYS xwas a > bad idea, the second step is to let userspace set the time instead. The > kernel can't take the proper decision because it simply doesn't know > whether userspace is TIME64 ready or not. It's been seven years since the you added the workaround, and there are a few things that have changed in the meantime: - most distros that use systemd have stopped supporting 32-bit targets - most distros that still support 32-bit have moved to a 64-bit time_t - 2038 is only 13 years away instead of 20, adding to the urgency of having future-proof default behavior. I don't know how many 32-bit machines are affected by the bug where they return a random time, or if they are more or less common than in the past. Probably some variant of my old patch is still appropriate now. Arnd
