Hi John, John Scott <[email protected]> writes:
> For a script I was writing, I tried to touch a file so that its modificatio= > n time would become the end of the current day, or the beginning of the nex= > t day, a distinction that's not important for my application. Therefore I c= > rafted the following command: > POSIXLY_CORRECT=3D1 touch -m -d $(date "+%Y-%m-%dT23:59:60") /tmp/foobar > > Setting POSIXLY_CORRECT doesn't actually make a difference here but I menti= > on it for completeness. On my system this prints >> touch: invalid date format =E2=80=982026-06-29T23:59:60=E2=80=99 > > I understand that this error comes from https://gitweb.git.savannah.gnu.org= > /gitweb/?p=3Dcoreutils.git;f=3Dsrc/touch.c;hb=3DHEAD#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://ww= > w.gnu.org/software/coreutils/manual/html_node/touch-invocation.html says fo= > r 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 s= > pecially 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 vari= > able, does not refer to a leap second, the resulting time shall be one seco= > nd after a time where SS is 59. > > So even if specifying the seconds as 60 would be invalid otherwise, or if t= > he 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 s= > ake of other applications using it, then this probably needs a workaround i= > n 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 Nice catch and thanks for the detailed report! I am thinking this will have to be implemented as a flag for parse_datetime2. You can see that lib/posixtm.c in Gnulib has the correct logic for handling this case, so it should be fairly straight forward. I'll have to think about it some more, though, since I am not sure if any changes have to be made with respect to relative time elements. Collin
