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: Mon, 30 Oct 2017 21:33:37 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9OF9-0001yP-Pe for emacs-orgmode@gnu.org; Tue, 31 Oct 2017 00:33:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9OF8-0005fN-Mr for emacs-orgmode@gnu.org; Tue, 31 Oct 2017 00:33:39 -0400 Received: from mail-qk0-x22e.google.com ([2607:f8b0:400d:c09::22e]:47190) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e9OF8-0005fE-Ih for emacs-orgmode@gnu.org; Tue, 31 Oct 2017 00:33:38 -0400 Received: by mail-qk0-x22e.google.com with SMTP id m189so18903848qke.4 for ; Mon, 30 Oct 2017 21:33:38 -0700 (PDT) In-Reply-To: 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: emacs-orgmode@gnu.org On Mon, Oct 30, 2017 at 5:40 PM, Allen Li wrote: > (current-time-string (time-to-seconds (org-2ft "<2017-10-31>"))) > "Sun Oct 29 17:00:00 2017" > > This seems wrong > > In org-2ft > > (org-parse-time-string s nil t) > > The t means use UTC instead of Emacs local time. > > However, Org translates into (float-time), which is in Emacs localtime. > > 1. SCHEDULED>"" compares a UTC time against a local time. > 2. Either org-2ft should be fixed to be localtime, or should be > (float-time) in UTC. > > I don't know how Org internals works, but my experience so far has > been that Emacs and *nix in general is very naive about timezones; a > naked timestamp is assumed to be localtime if it does not have > accompanying timezone information. > > Thus, it seems to be more correct to change org-2ft to parse times as > localtime. However, I don't know if UTC timestamps are assumed by > other parts of Org internals, in which case fixing (float-time) > would be safest. My initial analysis was wrong because I wasn't thinking clearly. Just to set a stake in the ground: timestamps are seconds since epoch and timezone neutral. Emacs time values are also timezone neutral: (sec-high sec-low microsec picosec) (current-time-string (float-time)) "Mon Oct 30 21:21:31 2017" ; right (current-time-string (org-time-today)) "Mon Oct 30 00:00:00 2017" ; right (current-time-string (org-2ft "<2017-10-31>")) "Mon Oct 30 17:00:00 2017" ; wrong Removing the t for zone fixes it (defun org-2ft (s) "Convert S to a floating point time. If S is already a number, just return it. If it is a string, parse it as a time string and apply `float-time' to it. If S is nil, just return 0." (cond ((numberp s) s) ((stringp s) (condition-case nil (float-time (apply #'encode-time (org-parse-time-string s))) (error 0.))) (t 0.))) (current-time-string (org-2ft "<2017-10-31>")) "Tue Oct 31 00:00:00 2017" ; now right 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. That is to say, nothing in Org allows passing in a custom timezone, let alone a UTC timezone; thus, every caller that passes a non-nil zone to org-parse-time-string is getting an incorrect result. tl;dr time is hard.