From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 29 16:24:54 2014 Received: (at submit) by debbugs.gnu.org; 29 Apr 2014 20:24:54 +0000 Received: from localhost ([127.0.0.1]:45545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WfEaD-0002TA-Ed for submit@debbugs.gnu.org; Tue, 29 Apr 2014 16:24:53 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60731) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WfETX-0002HJ-0R for submit@debbugs.gnu.org; Tue, 29 Apr 2014 16:17:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WfETQ-0002Pv-Qk for submit@debbugs.gnu.org; Tue, 29 Apr 2014 16:17:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfETQ-0002Pr-NI for submit@debbugs.gnu.org; Tue, 29 Apr 2014 16:17:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfETP-0003q4-Lj for bug-coreutils@gnu.org; Tue, 29 Apr 2014 16:17:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WfETN-0002OJ-VB for bug-coreutils@gnu.org; Tue, 29 Apr 2014 16:17:51 -0400 Received: from mail-oa0-x22a.google.com ([2607:f8b0:4003:c02::22a]:65174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfETN-0002O7-QG for bug-coreutils@gnu.org; Tue, 29 Apr 2014 16:17:49 -0400 Received: by mail-oa0-f42.google.com with SMTP id i7so862821oag.29 for ; Tue, 29 Apr 2014 13:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=R/hQt9xYlnWvONqMKw/q1rpun+A2tTYC+WPssw2N0+8=; b=bxp82s/wgAUktzVtKONySL1R3AfajCwlDloKMRXpXySqwE8Zq35vq1vrMMeAN4TQZ+ X+SEBdlMRfbh+X/Z5+hfE2geBSKUWfZsGervm+02tuUIB/rvmKbVTRIdLOpbc8wkhgjf QlQarvjIdSXtlKEXhbXqkCl88hhJ/NT7pjipkm/onfaWPkWA7nL/Q5UmKgRuKVvonPnf QpTXc3z0Cy3PLqLWSBSWgrfI7Q7xo6LqPoybaoDbChKPCJkh+cLoHv27QB8aQPaYxrjb muzzB+osgBKgUSdOLjEa6Kw992SDjZpJ3vMyMEsk4fs93YN2qYKTHDVR59ShAUqm1bWP nDlg== MIME-Version: 1.0 X-Received: by 10.60.155.72 with SMTP id vu8mr1429760oeb.60.1398802668983; Tue, 29 Apr 2014 13:17:48 -0700 (PDT) Received: by 10.76.10.193 with HTTP; Tue, 29 Apr 2014 13:17:48 -0700 (PDT) Date: Tue, 29 Apr 2014 16:17:48 -0400 Message-ID: Subject: issue with '/bin/date' resolving months via '-d DATESTR' From: Benjamin Richardson To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary=047d7bd6ab54321c4704f83420ae X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Tue, 29 Apr 2014 16:24:51 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --047d7bd6ab54321c4704f83420ae Content-Type: text/plain; charset=UTF-8 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 --047d7bd6ab54321c4704f83420ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I think my issue can best be des= cribed by demonstration. Here goes:

user@serv= er$ /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 F= ebruary, not March. I get that Feb 29 doesn't exist, so returning a dat= e that never happened might not make sense. But in simply asking for the mo= nth, not the full date of 2 months ago, could %B be calculated first, befor= e 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 mon= ths ago'
Sat Mar =C2=A01 14:57:45 EST 2014
user@ser= ver$ date -d '3 months ago'
Wed Jan 29 14:58:41 EST 2014<= /div>

Thanks!
Ben
--047d7bd6ab54321c4704f83420ae-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 29 18:31:07 2014 Received: (at control) by debbugs.gnu.org; 29 Apr 2014 22:31:07 +0000 Received: from localhost ([127.0.0.1]:45718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WfGYM-0005y5-KE for submit@debbugs.gnu.org; Tue, 29 Apr 2014 18:31:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33816) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WfGYH-0005xW-Nb; Tue, 29 Apr 2014 18:31:03 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3TMV0vh019753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Apr 2014 18:31:00 -0400 Received: from [10.3.113.132] (ovpn-113-132.phx2.redhat.com [10.3.113.132]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3TMUxud017439; Tue, 29 Apr 2014 18:31:00 -0400 Message-ID: <53602823.5090604@redhat.com> Date: Tue, 29 Apr 2014 16:30:59 -0600 From: Eric Blake Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Benjamin Richardson , 17374-done@debbugs.gnu.org Subject: Re: bug#17374: issue with '/bin/date' resolving months via '-d DATESTR' References: In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b2192gCWn5hcq1I2DHuxa6LDtmJSrbjW1" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --b2192gCWn5hcq1I2DHuxa6LDtmJSrbjW1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable tag 17374 notabug thanks On 04/29/2014 02:17 PM, Benjamin Richardson wrote: > Hello, >=20 > I think my issue can best be described by demonstration. Here goes: Thanks for the report and demonstration. >=20 > 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 >=20 > 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 month= s > 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-co= mmand-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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --b2192gCWn5hcq1I2DHuxa6LDtmJSrbjW1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTYCgjAAoJEKeha0olJ0NqPAgH/ihvthgqdNvTzt1E96LRGIxN Y8G1gFvXa4dpR2H/UHMnfHzc7ggcCR/Ewz1eu8+a7PcPTka7N+f9eWuNIa8mWPW1 7QT+r1LTVGdssW83ADe3XoT/f54kI/VcDvB4HmRjkxEymiWgMoZ0/bG1hUmMW+ed MHnCoo4IUKU8eBWJi1mxFwEqHPKK4940gYTNyVub1R7qDtZh40gziSh5mWL2rx63 sw+mDfDNT3uPL0V4EAD60tskvyCSWXybLy0Qx8BMihw37KR2BnzRDeJ+r6gcrYKz Uv3K0hn7bU8qVqKwuzUI8q8rOn8dUPDv4OGLL9gOWzCh+7JdvKIu1M/RCopjVKA= =JGeW -----END PGP SIGNATURE----- --b2192gCWn5hcq1I2DHuxa6LDtmJSrbjW1-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 30 14:57:22 2014 Received: (at 17374-done) by debbugs.gnu.org; 30 Apr 2014 18:57:22 +0000 Received: from localhost ([127.0.0.1]:46757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WfZh3-0004OO-Fv for submit@debbugs.gnu.org; Wed, 30 Apr 2014 14:57:22 -0400 Received: from nm47-vm1.bullet.mail.bf1.yahoo.com ([216.109.115.124]:34340) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WfZh0-0004O7-0R for 17374-done@debbugs.gnu.org; Wed, 30 Apr 2014 14:57:18 -0400 Received: from [98.139.215.140] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 30 Apr 2014 18:57:12 -0000 Received: from [98.139.212.247] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 30 Apr 2014 18:57:12 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 30 Apr 2014 18:57:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 506506.31805.bm@omp1056.mail.bf1.yahoo.com Received: (qmail 8421 invoked by uid 60001); 30 Apr 2014 18:57:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398884232; bh=ArWcSgBVcaOcMyNdow0P6Ezow9K/sXMzSlUVWb7Qgwk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1Uiv37OzTxjsD6WZBpAm2keypaoSP/9711ugg28ikOnXD8AaVwQ5XHhbXjqn6KcH3M+RqY2yC89uRyqb5Cs0SL07ngpuryETTPSaA7oWgqEKSuQABFl6TTZ1BN/s407AdjcI5OYAPkyk67fx5oa3YIMeNLsDxiW+XGYHPePPQ2U= X-YMail-OSG: ojJ4RnYVM1nLQ3UXh3xiJn9jQh9JPGd00MVkCdgK2d3jsqz k928LgBgU0eML6p5zZo8hbI7uL5EUJUhmaWYio40UDJBNFedBUwrapWUAcoV ejD6gQ2AtFDJ5NCgTMWmC7PuqWfCzmUUZ1p34PtyeWWzy_zlcAD.j_bA8bJt 3VrSLxNUFFOSHAwAsRm1IQlQgqpH5xXzQzH8Zcxq2z4Q0OuX0TOYOzTCwQzX yKK8rm9Xy4CbYlZL79ovsYTYjlX0d.DtE3KaNhy5FYq7D4FPnWCvNHieDvH1 8R_2Kfl4gFFo64WEU8oyLWiyqZ_Rq7h7c5RiD65hfKJzctzxBvEae3i4T4z. 8_D4EISb4qNG6BkErOACh21VSmFV8L53e0NaMBrghW9xlQIu0m30pr.1olTx cHe7yjbWUBLDtazSNk.uqYNxZNsDyryKLV6tXmc4l.JbOaeDLC7Y1VywbBJE 7JxlwbAgsEa4veeiLjaYcA7VydETfg0OLO8wo6kWnbYXQ2QV4N24wKX3eg5F KDr8DdTtqRYyS9Sb.ybvkCek6qbnC4mCfMlq4huV3376sb2.jxUE2C6WMZWT dwntH997h6AU.4aCtHL_WSmL_f5KtdaBY2FSRqf17w0TnwA-- Received: from [70.49.120.43] by web142605.mail.bf1.yahoo.com via HTTP; Wed, 30 Apr 2014 11:57:12 PDT X-Rocket-MIMEInfo: 002.001, RXJpYwpSZWFkIHRoZSBkb2N1bWVudGF0aW9uLsKgIFdoZW4gdGhlIHByZXZpb3VzIG1vbnRoIGhhcyAyOC8yOSBkYXlzIGFuZCB0b2RheSBpcyB0aGUgMzB0aCwgdGhlIHNvZnR3YXJlIGdvZXMgdG8gRmVicnVhcnkgMzAsIGFuZCBmaW5kcyBpdCBkb2VzIG5vdCBleGlzdC4gVGhlIGFsZ29yaXRobSB0aGVuIGJ1bXBzIHVwIHRoZSBtb250aCBhbmQgYWRkcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDI4IGFuZCAzMCB0byB0aGUgZGF5IG9mIHRoZSBidW1wZWQgdXAgbW9udGguIFRoZXJlZm9yZSwgYWNjb3JkaW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: <53602823.5090604@redhat.com> Message-ID: <1398884232.7730.YahooMailNeo@web142605.mail.bf1.yahoo.com> Date: Wed, 30 Apr 2014 11:57:12 -0700 (PDT) From: Leslie S Satenstein Subject: Re: bug#17374: issue with '/bin/date' resolving months via '-d DATESTR' To: Eric Blake , Benjamin Richardson , "17374-done@debbugs.gnu.org" <17374-done@debbugs.gnu.org> In-Reply-To: <53602823.5090604@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1082104826-850923511-1398884232=:7730" X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 17374-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Leslie S Satenstein List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) --1082104826-850923511-1398884232=:7730 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Eric=0ARead the documentation.=A0 When the previous month has 28/29 days an= d today is the 30th, the software goes to February 30, and finds it does no= t exist. The algorithm then bumps up the month and adds the difference betw= een 28 and 30 to the day of the bumped up month. Therefore, according to th= e algorithm, the month after issuing /bin/date -d '*2 months ago*' +%B=A0= =A0=A0=A0 becomes March.=A0 =0AHad you included the day, you would see it t= o be the 2nd of March.=0A=0A=0A=0A=0A=A0=0ARegards =0A=0A=A0Leslie=0A=0AMr.= Leslie Satenstein=0ASENT FROM MY OPEN SOURCE LINUX SYSTEM.=0A=0A=0A=0A=0A>= ________________________________=0A> From: Eric Blake = =0A>To: Benjamin Richardson ; 17374-done@d= ebbugs.gnu.org =0A>Sent: Tuesday, April 29, 2014 6:30 PM=0A>Subject: bug#17= 374: issue with '/bin/date' resolving months via '-d DATESTR'=0A> =0A>=0A>t= ag 17374 notabug=0A>thanks=0A>=0A>On 04/29/2014 02:17 PM, Benjamin Richards= on wrote:=0A>> Hello,=0A>> =0A>> I think my issue can best be described by = demonstration. Here goes:=0A>=0A>Thanks for the report and demonstration.= =0A>=0A>=0A>> =0A>> user@server$ /bin/date=0A>> Tue Apr 29 15:51:11 EDT 201= 4=0A>> user@server$ /bin/date -d 'last month' +%B=0A>> March=0A>> user@serv= er$ /bin/date -d '*2 months ago*' +%B=0A>> *March*=0A>> user@server$ /bin/d= ate -d '3 months ago' +%B=0A>> January=0A>> =0A>> I expected 2 months ago t= o be February, not March. I get that Feb 29=0A>> doesn't exist, so returnin= g a date that never happened might not make=0A>> sense. But in simply askin= g for the month, not the full date of 2 months=0A>> ago, could %B be calcul= ated first, before rolling over to March 1st?=0A>=0A>You have asked a FAQ:= =0A>=0A>https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-d= ate-command-is-not-working-right_002e=0A>=0A>While it might be feasible to = tweak the hueristics of how to roll over a=0A>non-uniform chunk of time, it= is almost certain that doing so will also=0A>break existing uses that have= come to rely on the current behavior of=0A>treating relative months as a m= ultiple of 30 days.=A0 Similar problems=0A>occur when trying to deal with h= ow to deal with 23- and 25-hour days=0A>around daylight savings, when movin= g by relative chunks of "days" which=0A>are typically 24 hours.=0A>=0A>The = FAQ describes how to do calculations relative to the 15th of a month=0A>(or= to noon for a day) so as to eliminate the chance of fuzzy hueristics=0A>pl= opping you on a point in time you weren't expecting, but which is=0A>still = valid in terms of the math performed when you actually stop and=0A>think ab= out what was done.=A0 As this is already documented, I'm not sure=0A>there = is much else we can do in the code base.=A0 Therefore, I'm closing=0A>this = bug, although you should feel free to add more comments or even=0A>better p= ropose patches.=0A>=0A>-- =0A>Eric Blake=A0 eblake redhat com=A0 =A0 +1-91= 9-301-3266=0A>Libvirt virtualization library http://libvirt.org=0A>=0A>=0A>= =0A> --1082104826-850923511-1398884232=:7730 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Eric
Read the documentation.  W= hen the previous month has 28/29 days and today is the 30th, the software g= oes to February 30, and finds it does not exist. The algorithm then bumps u= p the month and adds the difference between 28 and 30 to the day of the bum= ped up month. Therefore, according to the algorithm, the month after issuin= g /bin/date -d '*2 months ago*' +%B     becomes March.&= nbsp;
Had you included the day, you would see it to be the 2nd of March= .



 
Regards

 Leslie
Mr. Leslie Satenstein
S= ENT FROM MY OPEN SOURCE LINUX SYSTEM.
<= br style=3D"" class=3D"">=

<= blockquote class=3D"" style=3D"">
<= div style=3D"" class=3D"" dir=3D"ltr">
From: Eric B= lake <eblake@redhat.com>
To: Benjamin Richardson <benjamin.g.richardson@gmail.c= om>; 17374-done@debbugs.gnu.org
Sent: T= uesday, 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 bes= t be described by demonstration. Here goes:

Thanks for the report an= d demonstration.


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


You have asked a F= AQ:

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

While it might b= e 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 u= ses that have come to rely on the current behavior of
treating relative months as a multiple of 30 days.&nbs= p; Similar problems
occur when tryi= ng to deal with how to deal with 23- and 25-hour days
around daylight savings, when moving by relative chunk= s of "days" which
are typically 24 = hours.

The FAQ describes how to do calculations relative to the 15th of a month
(o= r to noon for a day) so as to eliminate the chance of fuzzy hueristics
plopping you on a point in time you wer= en'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 al= ready documented, I'm not sure
ther= e is much else we can do in the code base.  Therefore, I'm closing
this bug, although you should feel fre= e to add more comments or even
bett= er propose patches.

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



=
--1082104826-850923511-1398884232=:7730-- From unknown Sat Jun 14 19:39:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 29 May 2014 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator