Subject: bug#35632: date Parse of '13:00 + 2 hours' Broken.

From: Assaf Gordon <[email-masked]>
Date: Wed, 26 Jun 2019 08:53:43 -0600

tag 35632 notabug
close 35632
stop

Hello,

(sorry for the delayed reply)

On Wed, May 08, 2019 at 12:57:10PM +0100, Ralph Corderoy wrote:
> 
> Using date from coreutils 8.31-1 on Arch Linux.
> This surprised me.
> 
>     $ TZ=UTC0 /bin/date -d '1pm + 2 hours'
>     Wed  8 May 15:00:00 UTC 2019
>     $ TZ=UTC0 /bin/date -d '13:00 + 2 hours'
>     Wed  8 May 12:00:00 UTC 2019
> 
> The documentation doesn't suggest `1pm' and `13:00' are treated
> differently.  `--debug' helps.
> 
>     $ TZ=UTC0 /bin/date --debug -d '1pm + 2 hours'
>     date: parsed time part: 01:00:00pm
>     date: parsed relative part: +2 hour(s)
>     ...
>     $ TZ=UTC0 /bin/date --debug -d '13:00 + 2 hours'
>     date: parsed time part: 13:00:00 UTC+02
>     date: parsed relative part: +1 hour(s)
>     date: input timezone: parsed date/time string (+02)
>     ...
> 
> It looks like parsing is broken in the second case.

Thank you for for providing detailed output with "--debug",
makes things easier to troubleshoot.

When encountering a time string (HH:MM or HH:MM:SS) followed by a plus
sign and a number, date's parser *always* treats it as a timezone
(giving timezones higher priority than time adjustments).

> The result I wanted can also be obtained my omitting the `+'.
> 
>     $ TZ=UTC0 /bin/date -d '1pm 2 hours'
>     Wed  8 May 15:00:00 UTC 2019
>     $ TZ=UTC0 /bin/date -d '13:00 2 hours'
>     Wed  8 May 15:00:00 UTC 2019

And this is indeed one possibly solution.

Other similar issues are detailed here:
https://lists.gnu.org/archive/html/bug-coreutils/2018-10/msg00126.html

As such, I'm closing this ticket, but discussion can continue by
replying to this thread.

regards,
 - assaf