From: Allen Li <vianchielfaura@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org, Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]
Date: Wed, 1 Nov 2017 21:28:16 -0700 [thread overview]
Message-ID: <CAJr1M6cbVGL=r19tKgMoUX8FeGR9=spGgXJAkK-bvQ+rM3BLTA@mail.gmail.com> (raw)
In-Reply-To: <CAJr1M6fcoo8y7m90H4iWEZ1CO-xeMPq8hTLwicjfiDMQ6VFOww@mail.gmail.com>
I found another one (It is 2017-11-01 in local time for me)
(org-time= "<2017-11-01>" "<today>")
nil
This is also local timezone dependent.
Tim made the point that these floats are not intended to be Unix
timestamps and only used for comparison, but this implementation
detail leaks quite heavily. Furthermore, the value returned by
org-2ft for these comparisons isn't even constant.
For example (org-2ft "<2017-10-10 10:00:00>") returns 1507629600.0 for
me today, but in four days it will return a different value,
1507626000.0. Surprise, the offset from local time to UTC is not
constant, even on the same machine in the same timezone.
The most immediate impact of this is that all of Org mode's time
comparison functions will be wrong when called during a local time
offset change. For those of us who are lucky, this may be twice a
year, but for others who are unlucky, it may be multiple times per
year or month, up to the whims of the local government.
This is one of the reasons I think "we're just using them for
comparisons" doesn't excuse org-2ft doing its little time shift. The
other reason is all of the regressions that change caused, including
this current bug, and yet another is my gut instinct that this is a
poor design choice from a technical perspective as a software
engineer.
next prev parent reply other threads:[~2017-11-02 4:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 0:40 Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)] Allen Li
2017-10-31 4:33 ` Allen Li
2017-10-31 18:23 ` Nicolas Goaziou
2017-10-31 18:35 ` Allen Li
2017-10-31 18:52 ` Nicolas Goaziou
2017-11-01 5:07 ` Allen Li
2017-11-01 5:41 ` Tim Cross
2017-11-01 6:26 ` Allen Li
2017-11-01 7:18 ` Tim Cross
2017-11-01 8:28 ` Allen Li
2017-11-01 13:09 ` Tim Cross
2017-11-01 19:14 ` Allen Li
2017-11-01 19:21 ` Allen Li
2017-11-02 0:09 ` Tim Cross
2017-11-02 0:26 ` Allen Li
2017-11-02 3:27 ` Tim Cross
2017-11-02 4:05 ` Allen Li
2017-11-02 4:28 ` Allen Li [this message]
2017-11-02 4:49 ` Allen Li
2017-11-02 4:56 ` Tim Cross
2017-11-02 5:12 ` Allen Li
2017-11-02 16:19 ` Nick Dokos
2017-11-02 19:56 ` Tim Cross
2017-11-01 20:55 ` Nicolas Goaziou
2017-11-02 0:10 ` Allen Li
2017-11-02 9:35 ` Nicolas Goaziou
2017-11-02 11:12 ` Tim Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJr1M6cbVGL=r19tKgMoUX8FeGR9=spGgXJAkK-bvQ+rM3BLTA@mail.gmail.com' \
--to=vianchielfaura@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
--cc=theophilusx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).