Subject: bug#18159: Bugin getting 'last month' on last day of the month

From: Pádraig Brady <[email-masked]>
Date: Fri, 01 Aug 2014 11:43:48 +0100

On 07/31/2014 05:10 PM, [email-masked] 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.