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@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
