GNU bug report logs -
#38003
date --date=-1month gives same month today
Previous Next
Reported by: Ilja Honkonen <ilja.honkonen <at> fmi.fi>
Date: Thu, 31 Oct 2019 14:35:03 UTC
Severity: normal
Tags: notabug
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38003 in the body.
You can then email your comments to 38003 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#38003
; Package
coreutils
.
(Thu, 31 Oct 2019 14:35:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ilja Honkonen <ilja.honkonen <at> fmi.fi>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Thu, 31 Oct 2019 14:35:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello
Please CC me as I'm not on this list. Running date (GNU coreutils) 8.26
on fedora 30 today (date --utc -I: 2019-10-31) with --date=-1month gives
the same month which doesn't make sense:
$ date --utc -I --date=-1month
2019-10-01
I assume using --date=-31day also wouldn't work if run e.g. in beginning
of march so this looks like a bug. Same happens also without --utc and
-I. Thanks
Ilja
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#38003
; Package
coreutils
.
(Thu, 31 Oct 2019 17:03:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 38003 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
There will be a discontinuity as long as the months are different lengths.
In the current implementation there will be only one discontinuity per
month; the 1st of the month always goes back to the 1st of the preceding
month. The overlap into the next month continues linearly until "now" is
the 1st of the month.
If I understand correctly, you would prefer that on March 29th, 30th, and
31st, this command would return the same date (except on leap years)?
$ date --date=-1month +"%m-%d"
02-28
This would introduce one to three discontinuities per month, but the
calculated month difference always the preceding month.
On Thu, Oct 31, 2019 at 3:46 PM Ilja Honkonen <ilja.honkonen <at> fmi.fi> wrote:
> Hello
> Please CC me as I'm not on this list. Running date (GNU coreutils) 8.26
> on fedora 30 today (date --utc -I: 2019-10-31) with --date=-1month gives
> the same month which doesn't make sense:
> $ date --utc -I --date=-1month
> 2019-10-01
> I assume using --date=-31day also wouldn't work if run e.g. in beginning
> of march so this looks like a bug. Same happens also without --utc and
> -I. Thanks
> Ilja
>
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#38003
; Package
coreutils
.
(Thu, 31 Oct 2019 17:36:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 38003 <at> debbugs.gnu.org (full text, mbox):
tag 38003 notabug
close 38003
stop
Hello,
On 2019-10-31 2:34 a.m., Ilja Honkonen wrote:
> Please CC me as I'm not on this list. Running date (GNU coreutils) 8.26
> on fedora 30 today (date --utc -I: 2019-10-31) with --date=-1month
> gives the same month which doesn't make sense:
> $ date --utc -I --date=-1month
> 2019-10-01
date gained a "--debug" option that helps diagnosing the issue:
$ date --utc -I --debug --date=-1month
date: parsed relative part: -1 month(s)
[...]
date: using current date as starting value: '(Y-M-D) 2019-10-31'
[...]
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months <----
date: after date adjustment (+0 years, -1 months, +0 days),
date: new date/time = '(Y-M-D) 2019-10-01 17:29:20'
date: warning: month/year adjustment resulted in shifted dates:
date: adjusted Y M D: 2019 09 31 <----
date: normalized Y M D: 2019 10 01 <----
[...]
date: final: (Y-M-D) 2019-10-01 17:29:20 (UTC)
2019-10-01
------
Subtracting 1 month from October 31st results in September 31st.
Since the date doesn't exist, it is normalized:
September 31st is "one day after September 30th", which
results in October 1st.
The "--debug" option also warns: when subtracting months,
it is recommended to specify the 15th (middle) of the month,
exactly to avoid such issues.
$ date --utc -I --date="2019-10-15 -1month"
2019-09-15
regards,
- assaf
Added tag(s) notabug.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 31 Oct 2019 17:36:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
38003 <at> debbugs.gnu.org and Ilja Honkonen <ilja.honkonen <at> fmi.fi>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 31 Oct 2019 17:36:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#38003
; Package
coreutils
.
(Wed, 06 Nov 2019 15:16:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 38003 <at> debbugs.gnu.org (full text, mbox):
> Subtracting 1 month from October 31st results in September 31st.
> Since the date doesn't exist, it is normalized:
> September 31st is "one day after September 30th", which
> results in October 1st.
Thanks for explanation. To me it makes more sense that going one month
back from 31 oct, or last day of oct, would give last day of sep instead
of first day of oct. But now that I'm aware of this feature I can work
around it if needed.
Ilja
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 05 Dec 2019 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 283 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.