GNU bug report logs - #12162
[date] wrong time returned from provided relative date description

Previous Next

Package: coreutils;

Reported by: Andris Pavenis <andris.pavenis <at> iki.fi>

Date: Thu, 9 Aug 2012 07:47:01 UTC

Severity: normal

Done: Bob Proulx <bob <at> proulx.com>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#12162; Package coreutils. (Thu, 09 Aug 2012 07:47:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andris Pavenis <andris.pavenis <at> iki.fi>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Thu, 09 Aug 2012 07:47:02 GMT) Full text and rfc822 format available.

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

From: Andris Pavenis <andris.pavenis <at> iki.fi>
To: bug-coreutils <at> gnu.org
Subject: [date] wrong time returned from provided relative date description
Date: Thu, 09 Aug 2012 10:25:14 +0300
Noticed problems with command date:

[apavenis <at> callisto Test]$ ./date-test.sh
+ date
Thu Aug  9 10:16:31 EEST 2012
+ date -d '2 weeks ago'
Thu Jul 26 10:16:31 EEST 2012
+ date -d 'thursday 2 weeks ago'
Thu Jul 26 00:00:00 EEST 2012
+ date -d 'next month'
Sun Sep  9 10:16:31 EEST 2012
+ date -d '1 monday next month'
Thu Sep 13 00:00:00 EEST 2012
+ date -d '2 monday next month'
Thu Sep 20 00:00:00 EEST 2012

As one can see:

1) specifying both week day (eg. thursday) and week the actual
date is taken from week next to specified week. It should perhaps
be inside the specified week. The same happens if one uses
'this week', 'next week' etc.

2) specifying month and for example first monday generates
date not from the begin of the month but uses the day in current
month  as reference

Andris





Information forwarded to bug-coreutils <at> gnu.org:
bug#12162; Package coreutils. (Thu, 09 Aug 2012 08:20:02 GMT) Full text and rfc822 format available.

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

From: Andris Pavenis <andris.pavenis <at> iki.fi>
To: 12162 <at> debbugs.gnu.org
Subject: Tested coreutils versions
Date: Thu, 09 Aug 2012 11:10:54 +0300
Initially noticed on 8.4 (CentOS 6.3 x86_64). Also reproduced
with 8.10 and 8.12 (Fedora 16).





Information forwarded to bug-coreutils <at> gnu.org:
bug#12162; Package coreutils. (Thu, 09 Aug 2012 20:53:02 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: Andris Pavenis <andris.pavenis <at> iki.fi>
Cc: 12162 <at> debbugs.gnu.org
Subject: Re: bug#12162: [date] wrong time returned from provided relative
	date description
Date: Thu, 9 Aug 2012 14:43:42 -0600
tags 12162 + moreinfo
thanks

Andris Pavenis wrote:
> Noticed problems with command date:

Thanks for the report.  However I do not understand what problem you
are trying to report.  Showing the output that you expected would
help.

> [apavenis <at> callisto Test]$ ./date-test.sh
> + date
> Thu Aug  9 10:16:31 EEST 2012
> + date -d '2 weeks ago'

Here you are not specifying a time.  This is problematic.  Always
specify a time along with a date for robust usage.  Also knowing your
exact timezone would be helpful.  Also using the traditional output is
ambiguous.  Using -R produces a standard output that is unambiguous.

  $ TZ=US/Mountain date -R -d '12:00 2 weeks ago'
  Thu, 26 Jul 2012 12:00:00 -0600

See this reference for detailed information on this topic.

  http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

> Thu Jul 26 10:16:31 EEST 2012
> + date -d 'thursday 2 weeks ago'
> Thu Jul 26 00:00:00 EEST 2012

  $ TZ=US/Mountain date -R -d 'thursday 12:00 2 weeks ago'
  Thu, 26 Jul 2012 12:00:00 -0600

> + date -d 'next month'
> Sun Sep  9 10:16:31 EEST 2012

  $ TZ=US/Mountain date -R -d '12:00 next month'
  Sun, 09 Sep 2012 12:00:00 -0600

> + date -d '1 monday next month'
> Thu Sep 13 00:00:00 EEST 2012

  $ TZ=US/Mountain date -R -d '12:00 1 monday next month'
  Thu, 13 Sep 2012 12:00:00 -0600

> + date -d '2 monday next month'
> Thu Sep 20 00:00:00 EEST 2012

  $ TZ=US/Mountain date -R -d '12:00 2 monday next month'
  Thu, 20 Sep 2012 12:00:00 -0600

All of the above yield expected results.

> As one can see:
> 
> 1) specifying both week day (eg. thursday) and week the actual
> date is taken from week next to specified week. It should perhaps
> be inside the specified week. The same happens if one uses
> 'this week', 'next week' etc.

The date documentation says:

  28.6 Day of week items
  ======================

  The explicit mention of a day of the week will forward the date (only
  if necessary) to reach that day of the week in the future.
  ...
     A number may precede a day of the week item to move forward
  supplementary weeks.  It is best used in expression like `third
  monday'.  In this context, `last DAY' or `next DAY' is also acceptable;
  they move one week before or after the day that DAY by itself would
  represent.

Which explains specification in relation to the day of the week.

> 2) specifying month and for example first monday generates
> date not from the begin of the month but uses the day in current
> month  as reference

Yes.  This is also documented.  Here in the date documentation it says:

  28.7 Relative items in date strings
  ===================================

  "Relative items" adjust a date (or the current date if none) forward or
  backward.  The effects of relative items accumulate.  Here are some
  examples:

       1 year
       1 year ago
       3 years
       2 days

     The unit of time displacement may be selected by the string `year'
  or `month' for moving by whole years or months.  These are fuzzy units,
  as years and months are not all of equal duration.  More precise units
  are `fortnight' which is worth 14 days, `week' worth 7 days, `day'
  worth 24 hours, `hour' worth 60 minutes, `minute' or `min' worth 60
  seconds, and `second' or `sec' worth one second.  An `s' suffix on
  these units is accepted and ignored.

     The unit of time may be preceded by a multiplier, given as an
  optionally signed number.  Unsigned numbers are taken as positively
  signed.  No number at all implies 1 for a multiplier.  Following a
  relative item by the string `ago' is equivalent to preceding the unit
  by a multiplier with value -1.

The human date parsing code isn't very "tight" in that it is only a
partial attempt at reading human input and converting that to a time
value.  There are many traps.  In my opinion it is a feature that was
put into production too early.  But that is all water under the bridge
now.  It has been that way for a long time and now changing it would
certainly break current usage.

Bob




Added tag(s) moreinfo. Request was from Bob Proulx <bob <at> proulx.com> to control <at> debbugs.gnu.org. (Thu, 09 Aug 2012 20:53:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#12162; Package coreutils. (Wed, 12 Sep 2012 20:52:01 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: Andris Pavenis <andris.pavenis <at> iki.fi>
Cc: 12162 <at> debbugs.gnu.org
Subject: Re: bug#12162: [date] wrong time returned from provided relative
	date description
Date: Wed, 12 Sep 2012 14:50:28 -0600
tags 12162 - moreinfo
close 12162
thanks

I haven't seen a response to this in a month.  Therefore I am closing
the ticket as resolved.  If you have new information or clarification
please feel free to continue the discussion.

Bob





Removed tag(s) moreinfo. Request was from Bob Proulx <bob <at> proulx.com> to control <at> debbugs.gnu.org. (Wed, 12 Sep 2012 20:52:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 12162 <at> debbugs.gnu.org and Andris Pavenis <andris.pavenis <at> iki.fi> Request was from Bob Proulx <bob <at> proulx.com> to control <at> debbugs.gnu.org. (Wed, 12 Sep 2012 20:52:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 11 Oct 2012 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 12 years and 254 days ago.

Previous Next


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