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

Previous Next

Full log

Message #12 received at control <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.