Subject: bug#79078: date command: Relative dates fail with ISO 8601 time format and no zone

From: Pádraig Brady <[email-masked]>
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