bug#81331: touch -d doesn't allow a date_time string of YYYY-MM-DDThh:mm:60, which POSIX requires special behavior for

On 2026-06-29 20:28, Collin Funk wrote:
> I am thinking this will have to be implemented as a flag for
> parse_datetime2.

Although I wrote a patch to implement that merely by changing=20
src/touch.c (i.e., no changes to parse_datetime2, which is already=20
plenty complicated!), on further thought I am inclined to think this is=20
a bug in POSIX not in GNU 'touch', as the POSIX spec contradicts ISO=20
8601 which I don't think was intended. So I filed a bug report with the=20
POSIX folks here:

https://austingroupbugs.net/view.php?id=3D1991

Let's hold off on changing GNU 'touch' until the POSIX committee has a=20
chance to think about it. And if we do change GNU 'touch', my feeling is=20
that we should do so only if POSIXLY_CORRECT, as this business about :60=20
meaning the start of the next minute is surprising and can have=20
unexpected consequences.

In the meantime, the original reporter can get the behavior they=20
requested with touch's older -t option, e.g.:

touch -m -t $(date "+%Y%m%d2359.60") /tmp/foobar

and this should be portable to all POSIX platforms. I do recommend,=20
though, running it with TZ=3DUTC0 as it can fail in other timezones. For=20
example:

$ TZ=3DAmerica/Nuuk touch -m -t 202603282359.60 /tmp/foobar
touch: invalid date format =E2=80=98202603282359.60=E2=80=99

This is because there was no 23:59:59 that day in Nuuk: the clock jumped=20
forward an hour from 23:00 to 00:00 the next day, as the start of=20
daylight saving time. This may help to explain why I think this ":60"=20
business was a mistake.