GNU bug report logs -
#43759
Emacs Calc date conversion
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 43759 in the body.
You can then email your comments to 43759 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43759
; Package
emacs
.
(Fri, 02 Oct 2020 11:10:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Vincent Belaïche <vincent.b.1 <at> hotmail.fr>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 02 Oct 2020 11:10:02 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)]
My Emacs version is GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.6 (Build 19G73)) of 2020-07-29
I do the following expériment under Emacs CC
;; Set date format as Unix
dd U RET
;; Enter 1991-01-09T06:00 in Unix format, cf. date -d '1991-01-09T06:00+00' '+%s'
' <663400800> RET
;; Set format as ISO
dd YYYY-MM-DD HH:mm:SS RET
Then the display is <1991-01-10 06:00>, but I expected the 9th and not the 10th of January.
Vincent.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43759
; Package
emacs
.
(Fri, 02 Oct 2020 14:23:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 43759 <at> debbugs.gnu.org (full text, mbox):
Vincent Belaïche <vincent.b.1 <at> hotmail.fr> writes:
> I do the following expériment under Emacs CC
>
> ;; Set date format as Unix
> dd U RET
> ;; Enter 1991-01-09T06:00 in Unix format, cf. date -d '1991-01-09T06:00+00'
> '+%s'
> ' <663400800> RET
> ;; Set format as ISO
> dd YYYY-MM-DD HH:mm:SS RET
>
> Then the display is <1991-01-10 06:00>, but I expected the 9th and not
> the 10th of January.
I wondered whether this somehow had also been fixed by Mattias' recent
calc change to business days, but it hasn't -- I'm able to reproduce it
with the current trunk.
This is another off-by-one-day bug, though, so perhaps it's related to
the same change from a few years ago that changed day zero?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43759
; Package
emacs
.
(Fri, 02 Oct 2020 17:32:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 43759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
2 okt. 2020 kl. 16.22 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> This is another off-by-one-day bug, though, so perhaps it's related to
> the same change from a few years ago that changed day zero?
Actually this error is unrelated. It has been there since Calc was added to the Emacs tree in 2001: the number of days from the Calc epoch to start of Unix time was incorrectly given as 719164 but the correct number was 719162 before the change in Calc epoch in 2012, and since then it should be 719163.
The "t U" command was fixed in 2015 (e368697ce36) along with the documentation. The attached patch fixes the remaining uses of the wrong constant, in the date parsing and formatting code. Vincent, is this patch helpful?
[0001-Calc-fix-formatting-and-parsing-Unix-time-bug-43759.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#43759
; Package
emacs
.
(Fri, 02 Oct 2020 20:14:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Definitely, I applied the patch manually, and it fixed the issue.
VBR,
V.
________________________________
De : Mattias Engdegård <mattiase <at> acm.org>
Envoyé : vendredi 2 octobre 2020 19:31
À : Lars Ingebrigtsen <larsi <at> gnus.org>
Cc : Vincent Belaïche <vincent.b.1 <at> hotmail.fr>; 43759 <at> debbugs.gnu.org <43759 <at> debbugs.gnu.org>
Objet : Re: bug#43759: Emacs Calc date conversion
2 okt. 2020 kl. 16.22 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> This is another off-by-one-day bug, though, so perhaps it's related to
> the same change from a few years ago that changed day zero?
Actually this error is unrelated. It has been there since Calc was added to the Emacs tree in 2001: the number of days from the Calc epoch to start of Unix time was incorrectly given as 719164 but the correct number was 719162 before the change in Calc epoch in 2012, and since then it should be 719163.
The "t U" command was fixed in 2015 (e368697ce36) along with the documentation. The attached patch fixes the remaining uses of the wrong constant, in the date parsing and formatting code. Vincent, is this patch helpful?
[Message part 2 (text/html, inline)]
Reply sent
to
Mattias Engdegård <mattiase <at> acm.org>
:
You have taken responsibility.
(Fri, 02 Oct 2020 20:28:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Vincent Belaïche <vincent.b.1 <at> hotmail.fr>
:
bug acknowledged by developer.
(Fri, 02 Oct 2020 20:28:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 43759-done <at> debbugs.gnu.org (full text, mbox):
2 okt. 2020 kl. 22.13 skrev Vincent Belaïche <vincent.b.1 <at> hotmail.fr>:
> Definitely, I applied the patch manually, and it fixed the issue.
Thank you for the prompt confirmation (and the original report, of course)!
Pushed to master; closing bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 31 Oct 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 234 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.