Subject: bug#17374: closed (Re: bug#17374: issue with '/bin/date' resolving months via '-d DATESTR')

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 29 Apr 2014 22:32:03 +0000

Your bug report

#17374: issue with '/bin/date' resolving months via '-d DATESTR'

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
17374: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17374
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#17374: issue with '/bin/date' resolving months via '-d DATESTR'
From: Eric Blake <[email-masked]>
To: Benjamin Richardson <[email-masked]>, [email-masked]
Date: Tue, 29 Apr 2014 16:30:59 -0600
List-Id: <debbugs-submit.debbugs.gnu.org>

tag 17374 notabug
thanks

On 04/29/2014 02:17 PM, Benjamin Richardson wrote:
> Hello,
> 
> I think my issue can best be described by demonstration. Here goes:

Thanks for the report and demonstration.

> 
> user@server$ /bin/date
> Tue Apr 29 15:51:11 EDT 2014
> user@server$ /bin/date -d 'last month' +%B
> March
> user@server$ /bin/date -d '*2 months ago*' +%B
> *March*
> user@server$ /bin/date -d '3 months ago' +%B
> January
> 
> I expected 2 months ago to be February, not March. I get that Feb 29
> doesn't exist, so returning a date that never happened might not make
> sense. But in simply asking for the month, not the full date of 2 months
> ago, could %B be calculated first, before rolling over to March 1st?

You have asked a FAQ:

https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

While it might be feasible to tweak the hueristics of how to roll over a
non-uniform chunk of time, it is almost certain that doing so will also
break existing uses that have come to rely on the current behavior of
treating relative months as a multiple of 30 days.  Similar problems
occur when trying to deal with how to deal with 23- and 25-hour days
around daylight savings, when moving by relative chunks of "days" which
are typically 24 hours.

The FAQ describes how to do calculations relative to the 15th of a month
(or to noon for a day) so as to eliminate the chance of fuzzy hueristics
plopping you on a point in time you weren't expecting, but which is
still valid in terms of the math performed when you actually stop and
think about what was done.  As this is already documented, I'm not sure
there is much else we can do in the code base.  Therefore, I'm closing
this bug, although you should feel free to add more comments or even
better propose patches.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Subject: issue with '/bin/date' resolving months via '-d DATESTR'
From: Benjamin Richardson <[email-masked]>
To: [email-masked]
Date: Tue, 29 Apr 2014 16:17:48 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

I think my issue can best be described by demonstration. Here goes:

user@server$ /bin/date
Tue Apr 29 15:51:11 EDT 2014
user@server$ /bin/date -d 'last month' +%B
March
user@server$ /bin/date -d '*2 months ago*' +%B
*March*
user@server$ /bin/date -d '3 months ago' +%B
January

I expected 2 months ago to be February, not March. I get that Feb 29
doesn't exist, so returning a date that never happened might not make
sense. But in simply asking for the month, not the full date of 2 months
ago, could %B be calculated first, before rolling over to March 1st?

Here is some other potentially helpful info:

user@server$ rpm -qf /bin/date
coreutils-5.97-34.el5_8.1
user@server$ date -d '1 month ago'
Sat Mar 29 15:57:36 EDT 2014
user@server$ date -d '2 months ago'
Sat Mar  1 14:57:45 EST 2014
user@server$ date -d '3 months ago'
Wed Jan 29 14:58:41 EST 2014

Thanks!
Ben