GNU bug report logs -
#17374
issue with '/bin/date' resolving months via '-d DATESTR'
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17374 in the body.
You can then email your comments to 17374 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#17374; Package
coreutils.
(Tue, 29 Apr 2014 20:25:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Benjamin Richardson <benjamin.g.richardson <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Tue, 29 Apr 2014 20:25:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
I think my issue can best be described by demonstration. Here goes:
user <at> server$ /bin/date
Tue Apr 29 15:51:11 EDT 2014
user <at> server$ /bin/date -d 'last month' +%B
March
user <at> server$ /bin/date -d '*2 months ago*' +%B
*March*
user <at> 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 <at> server$ rpm -qf /bin/date
coreutils-5.97-34.el5_8.1
user <at> server$ date -d '1 month ago'
Sat Mar 29 15:57:36 EDT 2014
user <at> server$ date -d '2 months ago'
Sat Mar 1 14:57:45 EST 2014
user <at> server$ date -d '3 months ago'
Wed Jan 29 14:58:41 EST 2014
Thanks!
Ben
[Message part 2 (text/html, inline)]
Added tag(s) notabug.
Request was from
Eric Blake <eblake <at> redhat.com>
to
control <at> debbugs.gnu.org.
(Tue, 29 Apr 2014 22:32:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eric Blake <eblake <at> redhat.com>:
You have taken responsibility.
(Tue, 29 Apr 2014 22:32:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Benjamin Richardson <benjamin.g.richardson <at> gmail.com>:
bug acknowledged by developer.
(Tue, 29 Apr 2014 22:32:03 GMT)
Full text and
rfc822 format available.
Message #12 received at 17374-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> server$ /bin/date
> Tue Apr 29 15:51:11 EDT 2014
> user <at> server$ /bin/date -d 'last month' +%B
> March
> user <at> server$ /bin/date -d '*2 months ago*' +%B
> *March*
> user <at> 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
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17374; Package
coreutils.
(Wed, 30 Apr 2014 18:58:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 17374-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eric
Read the documentation. When the previous month has 28/29 days and today is the 30th, the software goes to February 30, and finds it does not exist. The algorithm then bumps up the month and adds the difference between 28 and 30 to the day of the bumped up month. Therefore, according to the algorithm, the month after issuing /bin/date -d '*2 months ago*' +%B becomes March.
Had you included the day, you would see it to be the 2nd of March.
Regards
Leslie
Mr. Leslie Satenstein
SENT FROM MY OPEN SOURCE LINUX SYSTEM.
>________________________________
> From: Eric Blake <eblake <at> redhat.com>
>To: Benjamin Richardson <benjamin.g.richardson <at> gmail.com>; 17374-done <at> debbugs.gnu.org
>Sent: Tuesday, April 29, 2014 6:30 PM
>Subject: bug#17374: issue with '/bin/date' resolving months via '-d DATESTR'
>
>
>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 <at> server$ /bin/date
>> Tue Apr 29 15:51:11 EDT 2014
>> user <at> server$ /bin/date -d 'last month' +%B
>> March
>> user <at> server$ /bin/date -d '*2 months ago*' +%B
>> *March*
>> user <at> 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
>
>
>
>
[Message part 2 (text/html, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 29 May 2014 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 18 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.