[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12162: [date] wrong time returned from provided relative date descri
From: |
Bob Proulx |
Subject: |
bug#12162: [date] wrong time returned from provided relative date description |
Date: |
Thu, 9 Aug 2012 14:43:42 -0600 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.
> address@hidden 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