Hello,

Debian

For a script I was writing, I tried to touch a file so that its modification 
time would become the end of the current day, or the beginning of the next day, 
a distinction that's not important for my application. Therefore I crafted the 
following command:
        POSIXLY_CORRECT=1 touch -m -d $(date "+%Y-%m-%dT23:59:60") /tmp/foobar

Setting POSIXLY_CORRECT doesn't actually make a difference here but I mention 
it for completeness. On my system this prints
> touch: invalid date format ‘2026-06-29T23:59:60’

I understand that this error comes from 
https://gitweb.git.savannah.gnu.org/gitweb/?p=coreutils.git;f=src/touch.c;hb=HEAD#l112

> /* The interpretation of FLEX_DATE as a date, relative to NOW.  */
> static struct timespec
> date_relative (char const *flex_date, struct timespec now)
> {
>       struct timespec result;
>       if (! parse_datetime (&result, flex_date, &now))
>               error (EXIT_FAILURE, 0, _("invalid date format %s"), quote 
> (flex_date));
>       return result;
> }

This is using parse_datetime() from Gnulib. For what it's worth, 
https://www.gnu.org/software/coreutils/manual/html_node/touch-invocation.html 
says for touch's similar -t option that, only on systems that support leap 
seconds, the seconds may be specified as 60.

However, POSIX Issue 7 and Issue 8 at 
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/touch.html require 
the touch utility to handle this specially so touch always works with seconds 
specified as 60:
> The range for SS is [00,60] rather than [00,59] because of leap seconds. If 
> SS is 60, and the resulting time, as affected by the TZ environment variable, 
> does not refer to a leap second, the resulting time shall be one second after 
> a time where SS is 59.

So even if specifying the seconds as 60 would be invalid otherwise, or if the 
locale or system doesn't recognize leap seconds, the touch utility needs to 
special case this and effectively "round up". If we assume the behavior of 
parse_datetime() is intentional and it needs to stay the same for the sake of 
other applications using it, then this probably needs a workaround in touch.c

This is observed using coreutils 9.7 on Debian GNU/Linux Trixie. It appears 
that Debian does *not* update the Gnulib modules before building, so they 
should be the same as when coreutils 9.7 was released. Thanks

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to