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/)]

[Tim Cross <theophilusx@gmail.com>]

I think this whole issue really requires a lot more analysis and
design. Just removing or cancelling various commits is unlikely to
improve matters and could result in new problems.

For org to work correctly, especially when interacting/interfacing with
other systems, such as external calendars, the use of timestamps must
handle timezones consistently and accurately. This is the only way that
any daylight savings calculations will work consistently as different
timezones have different rules for when daylight savings start/finish
(and these rules change).

If the tests only support UTC/GMT timezone, they are poor tests and need
to be adjusted to use whatever the timezone is on the system running the
tests.

I also wonder if there is some inconsistencies in how timestamps without
a time component are being handled. It would be good to know if the
issues Alan has observed exist when a full timestamp is used ie. one
with HH:MM:SS.s and not just date. If timezones are not been applied
consistently when choosing the default i.e. 00:00:00.0 with respect to
timezone offset, you will get inconsistencies when moving between
displayed (string) and calculated (number/seconds since epoch) values.

Tim


Allen Li <vianchielfaura@gmail.com> writes:

>  On Tue, Oct 31, 2017 at 11:52 AM, Nicolas Goaziou
> <mail@nicolasgoaziou.fr> wrote:
>> Allen Li <vianchielfaura@gmail.com> writes:
>>
>>> Can you clarify on the issues the UTC timezone fixes?
>>
>> At the moment, I can only give you a pointer, which is commit
>> 97a1a498956da2e1961df5a0506df4cbb98fff52. Some other commits followed
>> this one in maint and master.
>>
>> You may want to check the ML for the initial bug report.
>
> Bisecting on maint shows that this regression happened at
> cc5a9bf538a4a7eb1b84d368336c46cead106e01
>
> I tested using this command:
>
> find . -name "*.elc" -delete; emacs -Q --batch --eval "(add-to-list
> 'load-path default-directory)" --eval "(require 'org)" --eval "(princ
> (current-time-string (org-2ft \"<2017-10-31>\")))"
>
> I guess the relevant bug is
> http://lists.gnu.org/archive/html/emacs-orgmode/2017-07/msg00097.html,
> but oddly enough, I cannot reproduce that bug at
> cc5a9bf538a4a7eb1b84d368336c46cead106e01~1
>
> From what I can glean from the history,
> 112c5ba479d52c3c36de5c7aafd14ab6bc075005 is where things started to go
> wrong.  UTC timezone was added to tests.  From there, a number of
> commits were added to fix regressions.
>
> The problem is that the tests were made to assume UTC timezone and Org
> mode was changed to also use UTC timezone to make the tests pass;
> however, this means that org.el no longer works for non-UTC time
> zones.
>
> That commit's message (112c5ba479d52c3c36de5c7aafd14ab6bc075005) also
> seems suspect.  It claims to be removing DST offset by enforcing UTC.
> That could only be true for people using GMT.  In GMT during DST,
> enforcing UTC would "remove" the DST offset, but that is not true
> anywhere else.
>
> Given my chain of reasoning, the commits following
> 112c5ba479d52c3c36de5c7aafd14ab6bc075005 to fix "regressions" is
> really just converting all of Org mode's timestamps to use the
> "timezone adjusted" Unix timestamps introduced by
> 112c5ba479d52c3c36de5c7aafd14ab6bc075005


-- 
Tim Cross