On March 3, 2026 12:50:33 PM PST, Arnd Bergmann <[email protected]> wrote: >On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote: >> On 2026-02-27 01:34, Thomas Weißschuh wrote: >>>>> >>>> The thing about gettimeofday() and time() is that they don't have >>>> a 64-bit version and libc implementations are expected to call >>>> clock_gettime() instead. The result was that there was never a >>>> patch to turn the off either. >>> >>> gettimeofday() is currently the only way to get the timezone of the kernel. >>> But I guess this is a legacy thing anyways. If you say we should drop it, >>> let's drop it. >>> >> >> The time zone in the kernel has never worked anyway, as it would require the >> kernel to contain at least the forward portion of the zoneinfo/tzdata table >> in >> order to actually work correctly. The only plausible use of it would be for >> local time-based filesystems like FAT, but I don't think we bother. >> >> A bigger question is whether or not we should omit these from the vDSO >> completely (potentially causing link failures) or replace them with stubs >> returning -ENOSYS. > >I see no harm in keeping gettimeofday() in the vdso when >COMPAT_32BIT_TIME is turned on, as existing code will call it >no matter whether it's in the vdso or the syscall. > >Equally, I see no point in having either version of >gettimeofday() or settimeofday() when COMPAT_32BIT_TIME is >disabled, as clearly anything calling it would pass incorrect >data for times past 2038. > >Neither glibc nor musl support actually returning the kernel >timezone to callers of gettimeofday in modern versions that >support time64 syscalls. > > Arnd >
That wasn't the point. The point was what kind of error behavior we want.
