GNU bug report logs - #79078
date command: Relative dates fail with ISO 8601 time format and no zone

Previous Next

To reply to this bug, email your comments to 79078 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Geoff Kuenning <geoff <at> cs.hmc.edu>
To: bug-coreutils <at> gnu.org
Subject: date command: Relative dates fail with ISO 8601 time format and no
 zone
Date: Wed, 23 Jul 2025 00:56:34 -0700

Tested on coreutils 9.5 (gentoo) and 8.32 (OpenSuSE).

There seems to be an interesting interaction in the code that 
parses relative dates in the --date switch; relative 
specifications used with ISO 8601 base dates can give incorrect 
results.

All tests below were run with a time zone of America/Los_Angeles.

The following date commands work fine:

   $ date -d '2025-01-20T12:00:00Z +180 days'
   Sat Jul 19 05:00:00 AM PDT 2025
   $ date -d '2025-01-20T12:00:00-0800 +180 days'
   Sat Jul 19 01:00:00 PM PDT 2025

However, omitting the time zone gives a surprising result that's 
only one day later, and at a different time:

   $ date -d '2025-01-20T12:00:00 +180 days'
   Tue Jan 21 01:40:00 AM PST 2025

Omitting the zone offset, but not using a relative expression, 
works:

   $ date -d '2025-01-20T12:00:00'
   Mon Jan 20 12:00:00 PM PST 2025

Using hours in a relative expression without a time zone gives a 
different kind of error:

   $ date -d '2025-01-20T12:00:00 +4320 hours'
   date: invalid date ‘2025-01-20T12:00:00 +4320 hours’

But including the zone shows that the +4320 hours isn't the 
problem:

   $ date -d '2025-01-20T12:00:00-0800 +4320 hours'
   Sat Jul 19 01:00:00 PM PDT 2025

Using a non-ISO date format works with relative dates:

   date -d '12:00 PM Jan 20, 2025 + 180 days'
   Sat Jul 19 12:00:00 PM PDT 2025

Note: I haven't tested with all of the other accepted date 
formats.

A final note: from my POV, it would be fine to just reject ISO 
8601 strings that omitted the timezone.  However, in that case an 
error more informative than just "invalid date" would be helpful 
to users.
-- 
   Geoff Kuenning   geoff <at> cs.hmc.edu 
   https://www.cs.hmc.edu/~geoff/

"There's a true schizophrenia where if you say to voters, you 
know, do
you think the federal government spends too much money and they 
should
spend less, they say yeah, absolutely.  Then you name specific 
things,
like Pell grants for students and they say, no, not that.  How 
'bout
NIH, medical research funding?  Nah, you really shouldn't cut 
that.
And pretty soon you've proved that what the American public is 
against
is arithmetic."
       -- Bill Gates, March 10, 2011

Message #8 received at 79078 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Geoff Kuenning <geoff <at> cs.hmc.edu>, 79078 <at> debbugs.gnu.org
Subject: Re: bug#79078: date command: Relative dates fail with ISO 8601 time
 format and no zone
Date: Wed, 23 Jul 2025 11:49:47 +0100

tag 79078 notabug
close 79078
stop

Notes below...

On 23/07/2025 08:56, Geoff Kuenning via GNU coreutils Bug Reports wrote:
> Tested on coreutils 9.5 (gentoo) and 8.32 (OpenSuSE).
> 
> There seems to be an interesting interaction in the code that
> parses relative dates in the --date switch; relative
> specifications used with ISO 8601 base dates can give incorrect
> results.
> 
> All tests below were run with a time zone of America/Los_Angeles.
> 
> The following date commands work fine:
> 
>      $ date -d '2025-01-20T12:00:00Z +180 days'
>      Sat Jul 19 05:00:00 AM PDT 2025
>      $ date -d '2025-01-20T12:00:00-0800 +180 days'
>      Sat Jul 19 01:00:00 PM PDT 2025
> 
> However, omitting the time zone gives a surprising result that's
> only one day later, and at a different time:
> 
>      $ date -d '2025-01-20T12:00:00 +180 days'
>      Tue Jan 21 01:40:00 AM PST 2025

Adding --debug shows what's happening here:

  $ date --debug -d '2025-01-20T12:00:00 +180 days'
  date: parsed datetime part: (Y-M-D) 2025-01-20 12:00:00 UTC+02:20
  date: parsed relative part: +1 day(s)

I.e. the "+180" is taken as a POSIX timezone offset in minutes,
and the "days" is taken as a relative +1 day.

There are lots of combinations and edge cases in date inputs unfortunately.

cheers,
Padraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.