From mboxrd@z Thu Jan 1 00:00:00 1970 From: Allen Li 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 22:12:17 -0700 Message-ID: References: <87bmknkwhe.fsf@nicolasgoaziou.fr> <87tvyfjgjk.fsf@nicolasgoaziou.fr> <87tvyelb60.fsf@gmail.com> <87shdykuxc.fsf@gmail.com> <87r2thlewz.fsf@gmail.com> <87o9oll5r8.fsf@gmail.com> <874lqdth1r.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eA7nh-0007t1-4i for emacs-orgmode@gnu.org; Thu, 02 Nov 2017 01:12:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eA7ng-000208-2d for emacs-orgmode@gnu.org; Thu, 02 Nov 2017 01:12:21 -0400 Received: from mail-pf0-x22c.google.com ([2607:f8b0:400e:c00::22c]:45880) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eA7nf-0001yi-SQ for emacs-orgmode@gnu.org; Thu, 02 Nov 2017 01:12:19 -0400 Received: by mail-pf0-x22c.google.com with SMTP id d28so3739943pfe.2 for ; Wed, 01 Nov 2017 22:12:19 -0700 (PDT) In-Reply-To: <874lqdth1r.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Tim Cross Cc: emacs-orgmode@gnu.org, Nicolas Goaziou On Wed, Nov 1, 2017 at 9:56 PM, Tim Cross wrote: > > OK, thanks for the additional information. That helps a lot. > > We can now narrow down where the issue is. > > After having looked (only very casually) at some of the org date/time > related functions, I think there may be quite a few issues. I'm not > convinced the root cause is org-2ft converting to UTC, though I think > that change has probably revealed some of the issues. > > There does seem to be some inconsistency or lack of clarity regarding > some of these operations and it could well be that the switch to using > UTC is not the correct approach, but just switching back probably isn't > either What does appear to be required is increased consistency in some > of these functions or where/how they are used. . Thanks. I think I have been harping a bit too hard on org-2ft, but indeed it seems to be a bit more systemic an issue. > To correctly fix this, I feel more analysis is warranted. I'm prepared > to look at this and present a summary and options, but it will have to > wait until after 21st when I start leave from work. It is a complex area > and perhaps my skills won't be up to it, but I should at least be able > to identify the main areas needing attention/decisions. My initial approach would be to do some refactoring here, especially among org-2ft, org-matcher-time, and org-parse-time-string, each of which calls the others in a cycle and each share a part of the logic for interpreting Org mode timestamps. I'm not familiar with refactoring FOSS code via mailed patches, nor if Org maintainers would welcome such patches, but I would be willing to do some refactoring here. > > Whether we should change back to non-UTC for time comparisons in the > meantime is not something I feel informed enough to make a call. It > really depends on the daylight savings time related issues affecting > clock tables and other functionality. This is probably something core > org maintainers will need to make a call on. > > Tim