GNU bug report logs - #11115
linux date arithmetic

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11115 in the body.
You can then email your comments to 11115 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Karamuz <stefan <at> karamuz.pl>
To: bug-coreutils <at> gnu.org
Subject: linux date arithmetic
Date: Wed, 28 Mar 2012 14:39:11 +0200

[Message part 1 (text/plain, inline)]

Please check the 2 linux commands:

date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S
date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S

It's very confusing, because the results of the two commands differ in 
one hour and one minute, except of one minute only.

[~]$ date -d "$(date +%F\ %H:%M)" +%F\ %H:%M:%S
2012-03-28 14:06:00

... and after a few seconds:

[~]$ date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S
2012-03-28 15:07:20

It's a bug or I don't understand something?

The systems tested include:

Fedora 16
Centos 6.2
Debian *6.0.4

*Best Regards,

    Stefan Karamuz

[Message part 2 (text/html, inline)]

Message #8 received at 11115 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Stefan Karamuz <stefan <at> karamuz.pl>
Cc: bug-gnulib <bug-gnulib <at> gnu.org>, 11115 <at> debbugs.gnu.org
Subject: Re: bug#11115: linux date arithmetic
Date: Wed, 28 Mar 2012 11:50:34 -0600

[Message part 1 (text/plain, inline)]

[adding bug-gnulib]

On 03/28/2012 06:39 AM, Stefan Karamuz wrote:
> Please check the 2 linux commands:
> 
> date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S
> date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S
> 
> It's very confusing, because the results of the two commands differ in
> one hour and one minute, except of one minute only.
> 
> [~]$ date -d "$(date +%F\ %H:%M)" +%F\ %H:%M:%S
> 2012-03-28 14:06:00
> 
> ... and after a few seconds:
> 
> [~]$ date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S
> 2012-03-28 15:07:20

Thanks for the report.  It's easier to debug if you use the same
starting point for both commands rather than nesting an ever-changing
$(date) to feed the outermost 'date -d', but I can indeed reproduce your
behavior, as well as explain it:

$ date -d '2012-03-28 11:38'            +%H:%M:%S
11:38:00

Starting point.

$ date -d '2012-03-28 11:38 +1'         +%H:%M:%S
04:38:00

Aha - '11:38 +1' is parsed as a time zone designation.  In my case,
since I'm in UTC-6, or 7 time zones away from UTC+1, that explains why
my output jumped backwards by 7 hours; I'm assuming your location is at
UTC+2.

$ date -d '2012-03-28 11:38 +minute'    +%H:%M:%S
11:39:00

Notice that 'minute' can be parsed without units.

$ date -d '2012-03-28 11:38 + 1 minute' +%H:%M:%S
04:39:00

Therefore, the parser is faced with an ambiguity between:

(11:38 +1) minute
11:38 (+1 minute)

and happened to choose the result you consider to be less intuitive.
But looks what happen if you rearrange the command line:

$ date -d '+1 minute 2012-03-28 11:38'  +%H:%M:%S
11:39:00

Now there is no ambiguity.

I don't know if this is something adequately explained in our FAQ:
https://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

nor do I know if it might be possible to patch gnulib's getdate.y to
make the parsing smarter, but you are welcome to try patching it.  In
fact, I'd go so far as to say getdate.y has a bug; '+1' is a reasonable
time zone designator when it occurs after hh:mm, but I've never seen '+
1' meant as a time zone, so it seems like the presence of space after
'+' should be used to alter the parse precedence.

So I'm not sure whether to leave this bug open (in hopes of someone
writing a patch) or to close it (since the behavior is explainable, even
if not what you wanted, and can be worked around with a little
reordering on your part).

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#11115: linux date arithmetic
Date: Wed, 28 Mar 2012 19:16:15 +0100

On Wednesday 28 March 2012, Eric Blake wrote:
> [adding bug-gnulib]
>
> On 03/28/2012 06:39 AM, Stefan Karamuz wrote:
> > Please check the 2 linux commands:
> >
> > date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S
> > date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S
> >
> > It's very confusing, because the results of the two commands differ
> > in one hour and one minute, except of one minute only.
> >
> > [~]$ date -d "$(date +%F\ %H:%M)" +%F\ %H:%M:%S
> > 2012-03-28 14:06:00
> >
> > ... and after a few seconds:
> >
> > [~]$ date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S
> > 2012-03-28 15:07:20
>
> Thanks for the report.  It's easier to debug if you use the same
> starting point for both commands rather than nesting an ever-changing
> $(date) to feed the outermost 'date -d', but I can indeed reproduce
> your behavior, as well as explain it:
>
> $ date -d '2012-03-28 11:38'            +%H:%M:%S
> 11:38:00
>
> Starting point.
>
> $ date -d '2012-03-28 11:38 +1'         +%H:%M:%S
> 04:38:00
>
> Aha - '11:38 +1' is parsed as a time zone designation.  In my case,
> since I'm in UTC-6, or 7 time zones away from UTC+1, that explains
> why my output jumped backwards by 7 hours; I'm assuming your location
> is at UTC+2.
>
> $ date -d '2012-03-28 11:38 +minute'    +%H:%M:%S
> 11:39:00
>
> Notice that 'minute' can be parsed without units.

BTW I think that the parser syntax for -d got very unlucky implemented. 
IMO dates and intervals should have been clearly separated somehow. For 
me the parser is too much intelligent and does not what the user would 
expect.

Maybe there should be a separate option --add which takes only intervals 
(negative or positive) to be added to the stamp comming from -r,-d,-f 
or now.

cu,
Rudi

> $ date -d '2012-03-28 11:38 + 1 minute' +%H:%M:%S
> 04:39:00
>
> Therefore, the parser is faced with an ambiguity between:
>
> (11:38 +1) minute
> 11:38 (+1 minute)
>
> and happened to choose the result you consider to be less intuitive.
> But looks what happen if you rearrange the command line:
>
> $ date -d '+1 minute 2012-03-28 11:38'  +%H:%M:%S
> 11:39:00
>
> Now there is no ambiguity.
>
> I don't know if this is something adequately explained in our FAQ:
> https://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-w
>orking-right_002e
>
> nor do I know if it might be possible to patch gnulib's getdate.y to
> make the parsing smarter, but you are welcome to try patching it.  In
> fact, I'd go so far as to say getdate.y has a bug; '+1' is a
> reasonable time zone designator when it occurs after hh:mm, but I've
> never seen '+ 1' meant as a time zone, so it seems like the presence
> of space after '+' should be used to alter the parse precedence.
>
> So I'm not sure whether to leave this bug open (in hopes of someone
> writing a patch) or to close it (since the behavior is explainable,
> even if not what you wanted, and can be worked around with a little
> reordering on your part).

Message #14 received at 11115 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org
Cc: Eric Blake <eblake <at> redhat.com>, 11115 <at> debbugs.gnu.org,
	Stefan Karamuz <stefan <at> karamuz.pl>
Subject: Re: bug#11115: linux date arithmetic
Date: Wed, 28 Mar 2012 23:23:34 +0200

Eric Blake wrote:
> the parser is faced with an ambiguity between:
> 
> (11:38 +1) minute
> 11:38 (+1 minute)

What is the first interpretation meant to mean?
"10:38 minute" or "12:38 minute" is not a time designation I have ever heard
in spoken nor written English.

If you ditch this interpretation, there is no ambiguity.

Bruno

Message #17 received at 11115 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: bug-gnulib <at> gnu.org, 11115 <at> debbugs.gnu.org,
	Stefan Karamuz <stefan <at> karamuz.pl>
Subject: Re: bug#11115: linux date arithmetic
Date: Wed, 28 Mar 2012 15:59:28 -0600

[Message part 1 (text/plain, inline)]

On 03/28/2012 03:23 PM, Bruno Haible wrote:
> Eric Blake wrote:
>> the parser is faced with an ambiguity between:
>>
>> (11:38 +1) minute
>> 11:38 (+1 minute)
> 
> What is the first interpretation meant to mean?

The time 11:38 in the timezone UTC+1, plus the unit represented by 'minute'.

> "10:38 minute" or "12:38 minute" is not a time designation I have ever heard
> in spoken nor written English.

True, 'minute' in isolation, without a 'plus one' qualifier, is unusual;
but we have to continue to parse it in isolation since scripts may now
be relying on it.

> 
> If you ditch this interpretation, there is no ambiguity.

Yes, we're in violent agreement here: the added context of a +1 (and in
particular, of a '+ 1' with a space after the +), should indeed favor
the spoken preference of a time with no timezone, followed by a
completed relative designation; rather than of a relative designation
with only an implied quantity.  It's just that getdate.y is a hairy mess
to properly implement that change without breaking other worthwhile
constructs, so I won't be the one volunteering.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ruediger Meier <sweet_f_a <at> gmx.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#11115: linux date arithmetic
Date: Thu, 29 Mar 2012 02:17:11 +0100

On Wednesday 28 March 2012, Eric Blake wrote:
> On 03/28/2012 03:23 PM, Bruno Haible wrote:
> > Eric Blake wrote:
> >> the parser is faced with an ambiguity between:
> >>
> >> (11:38 +1) minute
> >> 11:38 (+1 minute)
> >
> > What is the first interpretation meant to mean?
>
> The time 11:38 in the timezone UTC+1, plus the unit represented by
> 'minute'.
>
> > "10:38 minute" or "12:38 minute" is not a time designation I have
> > ever heard in spoken nor written English.
>
> True, 'minute' in isolation, without a 'plus one' qualifier, is
> unusual; but we have to continue to parse it in isolation since
> scripts may now be relying on it.
>
> > If you ditch this interpretation, there is no ambiguity.
>
> Yes, we're in violent agreement here: the added context of a +1 (and
> in particular, of a '+ 1' with a space after the +), should indeed
> favor the spoken preference of a time with no timezone, followed by a
> completed relative designation; rather than of a relative designation
> with only an implied quantity.  It's just that getdate.y is a hairy
> mess to properly implement that change without breaking other
> worthwhile constructs, so I won't be the one volunteering.

BTW there is an interesting dateutils project not yet finished but worth 
to have look
https://github.com/hroptatyr/dateutils

cu,
Rudi

Message #23 received at 11115 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: bug-gnulib <at> gnu.org, 11115 <at> debbugs.gnu.org,
	Stefan Karamuz <stefan <at> karamuz.pl>
Subject: Re: bug#11115: linux date arithmetic
Date: Thu, 29 Mar 2012 11:21:40 +0200

Eric Blake wrote:
> > "10:38 minute" or "12:38 minute" is not a time designation I have ever heard
> > in spoken nor written English.
> 
> True, 'minute' in isolation, without a 'plus one' qualifier, is unusual;
> but we have to continue to parse it in isolation since scripts may now
> be relying on it.

No, we don't have to support syntaxes that are not documented and that
were only accidentally supported. Scripts may rely on documented features,
not on undocumented ones.

The doc in parse-datetime.texi explains that the literal word 'minute'
occurs only as part of a displacement. Thus it has to follow a number.
It can not occur after a literal time ("10:38" or "12:38") nor after a
time with displacement ("11:38 +1").

IMO spaces are irrelevant in this discussion.

> It's just that getdate.y is a hairy mess
> to properly implement that change without breaking other worthwhile
> constructs

I would remove the "tMINUTE_UNIT" alternative from 'relunit' and move it
instead to the rules that invoke 'relunit' and that need this alternative.

Bruno

Message #26 received at 11115 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Stefan Karamuz <stefan <at> karamuz.pl>, 11115 <at> debbugs.gnu.org
Subject: Re: bug#11115: linux date arithmetic
Date: Mon, 15 Oct 2018 10:40:01 -0600

tags 11115 notabug
close 11115
stop

(triaging old bugs)

Hello,

On 28/03/12 06:39 AM, Stefan Karamuz wrote:
> Please check the 2 linux commands:
> 
> date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S
> date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S
> 
> It's very confusing, because the results of the two commands differ in 
> one hour and one minute, except of one minute only.

In version 8.26 (released 2016) date gained the "--debug"
option which can help in understanding such issues.
The "+1" is taken to be "UTC+1" time zone, as shown here:

  $ date --debug -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S 

  date: parsed date part: (Y-M-D) 2018-10-15
  date: parsed time part: 10:35:21
  date: input timezone: system default
  [...]

  $ date --debug -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S 

  date: parsed date part: (Y-M-D) 2018-10-15
  date: parsed time part: 10:35:27 UTC+01
  date: parsed relative part: +1 minutes
  date: input timezone: parsed date/time string (+01)
  [...]


I'm closing this bug, but discussion can continue by replying to this 
thread.

regards,
 - assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.