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
src/touch.c (i.e., no changes to parse_datetime2, which is already
plenty complicated!), on further thought I am inclined to think this is
a bug in POSIX not in GNU 'touch', as the POSIX spec contradicts ISO
8601 which I don't think was intended. So I filed a bug report with the
POSIX folks here:
https://austingroupbugs.net/view.php?id=1991
Let's hold off on changing GNU 'touch' until the POSIX committee has a
chance to think about it. And if we do change GNU 'touch', my feeling is
that we should do so only if POSIXLY_CORRECT, as this business about :60
meaning the start of the next minute is surprising and can have
unexpected consequences.
In the meantime, the original reporter can get the behavior they
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,
though, running it with TZ=UTC0 as it can fail in other timezones. For
example:
$ TZ=America/Nuuk touch -m -t 202603282359.60 /tmp/foobar
touch: invalid date format ‘202603282359.60’
This is because there was no 23:59:59 that day in Nuuk: the clock jumped
forward an hour from 23:00 to 00:00 the next day, as the start of
daylight saving time. This may help to explain why I think this ":60"
business was a mistake.
