bug#26293: GNU date program

[Assaf Gordon]

tags 26293 notabug
close 26293
stop

Hello,

> On Mar 28, 2017, at 22:26, Dean Gibson AE7Q <address@hidden> wrote:
> 
> Consider: "date -d '2017-03-28 17:12:34 + 3 hours'"

Due to the way date strings are parsed, the "+3" part is used as the input time 
zone (+03:00) and then the "hours" part is taken as adding one hour.

> If I insert "PDT" in the original string after the time, it works on both 
> servers.

Yes, once the parser sees an explicit timezone (PDT), it deduces the rest is a 
relative time ("+3 hours").


> On both servers, "date -d '2017-03-28 17:12:34 3 hours ago'" works. Is there 
> a "3 hours ahead"-type phrase???

Yes, simply writing "3 hours" means "3 hours ahead".

Additionally,
The 'date' command in coreutils 8.27 has a new "--debug" option that displays
details about the parsed string, helping in diagnosing such issues.

Compare the following examples:

"+3" treated as timezone:

  $ date --debug -d '2017-03-28 17:12:34 + 3 hours'
  date: parsed date part: (Y-M-D) 2017-03-28
  date: parsed time part: 17:12:34 TZ=+03:00
  date: parsed relative part: +1 hour(s)
  date: input timezone: +03:00 (set from parsed date/time string)
  ...

Adding "PDT" works, but not the desired solution:

  $ date --debug -d '2017-03-28 17:12:34 PDT + 3 hours'
  date: parsed date part: (Y-M-D) 2017-03-28
  date: parsed time part: 17:12:34
  date: parsed zone part: TZ=-07:00
  date: parsed relative part: +3 hour(s)
  date: input timezone: -07:00 (set from parsed date/time string)
  ...

"3 hours" works:

  $ date --debug -d '2017-03-28 17:12:34 3 hours'
  date: parsed date part: (Y-M-D) 2017-03-28
  date: parsed time part: 17:12:34
  date: parsed relative part: +3 hour(s)
  ...


I'm marking this as "not-a-bug", but the discussion can continue by
replying to this thread.

regards,
 - assaf