On Tue, Oct 31, 2017 at 11:23 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Allen Li <vianchielfa...@gmail.com> 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.