GNU bug report logs - #18159
Bugin getting 'last month' on last day of the month

Previous Next

Package: coreutils;

Reported by: jemail2013 <at> comcast.net

Date: Thu, 31 Jul 2014 17:17:03 UTC

Severity: normal

Tags: notabug

Merged with 11098, 11101, 11125, 15785, 18479, 20523

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: jemail2013 <at> comcast.net
Cc: 18159 <at> debbugs.gnu.org
Subject: bug#18159: Bugin getting 'last month' on last day of the month
Date: Fri, 01 Aug 2014 11:43:48 +0100
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.