Paul Eggert <[email protected]> writes:
> Although I don't know what the bug is, would it be fixed by reverting
> coreutils commit b64f9bfe4fd4ce5d276626fd149af2a625b6d434, which I am
> attaching for convenience? I had forgotten about posixtime when I made
> that commit. Reverting that coreutils commit might be better than
> complicating Gnulib, as I don't expect many other uses for
> posixtime_z.
Yes, I am pretty sure reverting that change would fix it. For context,
it was reported as ANT-2026-LR8TONF4. To skip over the overly wordy
description in that, here is a simple demonstration:
$ date --version | head -n 1
date (GNU coreutils) 9.12.100-e3dd28
$ TZ="America/Los_Angeles" date -u 0101120026
date: cannot set date: Operation not permitted
Thu Jan 1 08:00:00 PM UTC 2026
$ podman run --rm -it fedora:43
$ date --version | head -n 1
date (GNU coreutils) 9.7
$ TZ="America/Los_Angeles" date -u 0101120026
date: cannot set date: Operation not permitted
Thu Jan 1 12:00:00 UTC 2026
I suspect not many people on GNU/Linux use 'date' for setting the date,
where 'timedatectl' is commonly used, if even needed, since most
installers will set up NTP for you. Evidently, I forgot about it as well
when reviewing your patch, since I never use that time format.
I am fine with just reverting that change and keeping gnulib as-is. I
see now that coreutils is the only one that uses that module:
$ grep -F posixtm used-modules/*
used-modules/coreutils: posixtm
used-modules/dc3dd:posix-shell posixtm posixver putenv
My understanding is that dc3dd is GNU 'dd' with some additional
features. I assume they just try to keep the build side of things
aligned with coreutils for ease of maintenance. 'dd' shouldn't actually
need that module.
Feel free to revert, and I can do a follow-up commit with a NEWS entry
and test, unless you are in the mood to do that, of course. :)
Collin
