GNU bug report logs -
#18159
Bugin getting 'last month' on last day of the month
Previous Next
Full log
View this message in rfc822 format
On 07/31/2014 05:10 PM, jemail2013 <at> comcast.net wrote:
> Hi,
> Today is July 31st. I am trying to get the last month and the result is still 07 which is the current month. Also, the day for the last month is returned as '01'.
> This worked correctly yesterday, July 30th. So, I think that there is a bug running it on the last day of the month.
> Either that, I am doing something silly :-).
>
> But please check.
>
> [M1]->date +'%Y%m%d'
> 20140731
>
>
> [M1]->date +'%Y%m%d' -d ' last month '
> 20140701
>
> [M1]->date +'%Y%m%d' -d ' 2 months ago '
> 20140531
This issue with relative date calculations is documented at:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
The issue is that last month isn't context sensitive and will
substract a fixed amount of time, not appropriate at the end of all months.
So simplifying your example a bit, you get this issue:
$ date
Thu Jul 31 11:35:29 IST 2014
$ date +'%m'
07
$ date +'%m' -d ' last month '
07
The same thing happens with `date -d yesterday +%F` going back 2 days around DST.
Personally I do think that's a bug that we could avoid.
I.E. the `date` command should be doing higher level operations with relative items.
I.E. it should not simply degenerate 1 day to 86400 seconds, etc.
Logic would be something like:
if (relative_input)
{
relative_unit = HCF (relative_input_unit, output_unit);
start_adjustment = get_middle_of_unit (relative_unit);
}
else
start_adjustment = 0;
if relative_unit > 0
start_adjustment = - start_adjustment;
start += start_adjustment;
I can't see anyone depending on the problematic old behavior?
thanks,
Pádraig.
This bug report was last modified 6 years and 207 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.