bug#37921: date -d "a day ago" differs from date -d "1 day ago"

[Eric Blake]

On 10/25/19 8:59 AM, Matt Carter wrote:
> When I ask date(1) for the date "a day ago", I get a different result from
> when I ask date(1) for the date "1 day ago".
> The results differ by 3 hours.
>
> If I ask for UTC time, the results differ by 1 hour.
>
> I'm not able to find anything in the manual to explain this difference.
> I realize making sense of a natural language specification of a date is 
> complicated.  Still, I wonder whether the difference in behavior is intentional 
> and if so why.

Here's what --debug says about it:

$ date -d 'a day ago' --debug
date: parsed zone part: UTC-01
date: parsed relative part: -1 day(s)
date: input timezone: parsed date/time string (-01)
date: using current time as starting value: '11:04:45'
date: using current date as starting value: '(Y-M-D) 2019-10-25'
date: starting date/time: '(Y-M-D) 2019-10-25 11:04:45 TZ=-01'
date: warning: when adding relative days, it is recommended to specify noon
date: after date adjustment (+0 years, +0 months, -1 days),
date:     new date/time = '(Y-M-D) 2019-10-24 11:04:45 TZ=-01'
date: '(Y-M-D) 2019-10-24 11:04:45 TZ=-01' = 1571918685 epoch-seconds
date: timezone: system default
date: final: 1571918685.899046321 (epoch-seconds)
date: final: (Y-M-D) 2019-10-24 12:04:45 (UTC)
date: final: (Y-M-D) 2019-10-24 07:04:45 (UTC-05)
Thu 24 Oct 2019 07:04:45 AM CDT

$ date -d '1 day ago' --debug
date: parsed relative part: -1 day(s)
date: input timezone: system default
date: using current time as starting value: '11:04:48'
date: using current date as starting value: '(Y-M-D) 2019-10-25'
date: starting date/time: '(Y-M-D) 2019-10-25 11:04:48'
date: warning: when adding relative days, it is recommended to specify noon
date: after date adjustment (+0 years, +0 months, -1 days),
date:     new date/time = '(Y-M-D) 2019-10-24 11:04:48'
date: '(Y-M-D) 2019-10-24 11:04:48' = 1571933088 epoch-seconds
date: timezone: system default
date: final: 1571933088.826463951 (epoch-seconds)
date: final: (Y-M-D) 2019-10-24 16:04:48 (UTC)
date: final: (Y-M-D) 2019-10-24 11:04:48 (UTC-05)
Thu 24 Oct 2019 11:04:48 AM CDT

So it is treating 'a' as the military time zone designator (a fixed 
distance from UTC), rather than as an English article meaning 1; the 
difference in results occurs if your current time zone differs from the 
'a' time zone.

> If you think this is a bug and you'd like a fix, I'd be happy to supply one.  
> Just let me know.  Thanks.

You're welcome to try and improve the parser, but it may not be trivial. 
 The master source code for the parser (shared among several GNU 
projects) is in the gnulib repository.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org