Re: [O] 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]

On Tue, Oct 31, 2017 at 11:23 AM, Nicolas Goaziou
<address@hidden> wrote:
> Hello,
>
> Allen Li <address@hidden> writes:
>
>> Removing the t for zone fixes it
>
> [...]
>
>> I will also note that the FIXME comment in org-parse-time-string
>> suggests that it too is not handling timezones correctly.  In fact,
>> perhaps org-parse-time-string should not take a zone argument, since
>> Org does not support timezones thus the only valid value for zone is
>> nil.  I suspect that org-display-custom-time, another caller that
>> passes t for zone, is also timezone incorrect.
>
> Both changes were introduced to fix some issues with daylight saving
> time, in particular in clock reports. It is not possible to simply
> suggest reverting them without considering the underlying issues.
>
> I agree there are issues to fix. Unfortunately, the solution you suggest
> is not sufficient.

Let me clarify the exact behavior that needs to be fixed.

Assuming today is 2017-10-31, SCHEDULED<"<now>" will match results
that have SCHEDULED=<2017-11-01> depending on your local time zone.

Can you clarify on the issues the UTC timezone fixes?  Because my
understanding at this point is that Org timestamps should be
interpreted as localtime, yet they are being interpreted as UTC time.
I can't see how, e.g.,  if I am in timezone UTC-5, I want all my Org
timestamps <2017-11-01> to be interpreted as <2017-10-31 19:00>.

Assuming that is in fact the behavior we want for some reason, then
<now>, or rather everywhere (float-time) is used in Org mode, should
receive a corresponding time shift.