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

Previous Next

Full log

View this message in rfc822 format

From: Bob Proulx <bob <at> proulx.com>
To: Andris Pavenis <andris.pavenis <at> iki.fi>
Cc: 12162 <at> debbugs.gnu.org
Subject: 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

Previous Next

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