|
From: | GNU bug Tracking System |
Subject: | [debbugs-tracker] bug#17374: closed (issue with '/bin/date' resolving months via '-d DATESTR') |
Date: | Tue, 29 Apr 2014 22:32:03 +0000 |
Your message dated Tue, 29 Apr 2014 16:30:59 -0600 with message-id <address@hidden> and subject line Re: bug#17374: issue with '/bin/date' resolving months via '-d DATESTR' has caused the debbugs.gnu.org bug report #17374, regarding issue with '/bin/date' resolving months via '-d DATESTR' to be marked as done. (If you believe you have received this mail in error, please contact address@hidden) -- 17374: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17374 GNU Bug Tracking System Contact address@hidden with problems
--- Begin Message ---Subject: issue with '/bin/date' resolving months via '-d DATESTR' Date: Tue, 29 Apr 2014 16:17:48 -0400 Hello,I think my issue can best be described by demonstration. Here goes:address@hidden /bin/dateTue Apr 29 15:51:11 EDT 2014address@hidden /bin/date -d 'last month' +%BMarchaddress@hidden /bin/date -d '2 months ago' +%BMarchaddress@hidden /bin/date -d '3 months ago' +%BJanuaryI 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:address@hidden rpm -qf /bin/datecoreutils-5.97-34.el5_8.1address@hidden date -d '1 month ago'Sat Mar 29 15:57:36 EDT 2014address@hidden date -d '2 months ago'Sat Mar 1 14:57:45 EST 2014address@hidden date -d '3 months ago'Wed Jan 29 14:58:41 EST 2014Thanks!Ben
--- End Message ---
--- Begin Message ---Subject: Re: bug#17374: issue with '/bin/date' resolving months via '-d DATESTR' Date: Tue, 29 Apr 2014 16:30:59 -0600 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 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. > > address@hidden /bin/date > Tue Apr 29 15:51:11 EDT 2014 > address@hidden /bin/date -d 'last month' +%B > March > address@hidden /bin/date -d '*2 months ago*' +%B > *March* > address@hidden /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.orgsignature.asc
Description: OpenPGP digital signature
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |