bug#79078: date command: Relative dates fail with ISO 8601 time format and no zone
Pádraig Brady <[email protected]>
| Newsgroups | gmane.comp.gnu.core-utils.bugs |
|---|---|
| Message-ID | <[email protected]> |
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