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 01:28:26 -0700 Message-ID: References: <87bmknkwhe.fsf@nicolasgoaziou.fr> <87tvyfjgjk.fsf@nicolasgoaziou.fr> <87tvyelb60.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]:40141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9oNx-0000Zl-DA for emacs-orgmode@gnu.org; Wed, 01 Nov 2017 04:28:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9oNw-0007KY-G9 for emacs-orgmode@gnu.org; Wed, 01 Nov 2017 04:28:29 -0400 Received: from mail-qk0-x22d.google.com ([2607:f8b0:400d:c09::22d]:57185) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e9oNw-0007KT-Bi for emacs-orgmode@gnu.org; Wed, 01 Nov 2017 04:28:28 -0400 Received: by mail-qk0-x22d.google.com with SMTP id l194so1739926qke.13 for ; Wed, 01 Nov 2017 01:28:28 -0700 (PDT) In-Reply-To: <87tvyelb60.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 12:18 AM, Tim Cross wrote: > > My preferences would be > > 1. If a timestamp does not include the TZ, then assume the local TZ > 2. If a timestamp does include the TZ, honour that TZ Org mode does not support TZ in time strings and adding support isn't the topic of the current bug. I want to emphasize the distinction between timestamps and time strings. Timestamps are a float value, Unix timestamps. Time strings are Org mode specific, like <2017-10-30 12:34:56> Timestamps do not have timezone information since they describe an exact (well, minus leap seconds) point in time, the number of seconds after the epoch. > 3. If the timestamp does not include a time component, default to 0:00:0 This is what Org mode does > for the local TZ This is what Org mode used to do, now it interprets it as 00:00:00 UTC. > 4. org-2ft should not enforce the UTC TZ. I agree this is incorrect. > > Rationale is that the user should have ability to fully control how > their timestamps are represented. However, adding the TZ is probably > just a pain for the majority of use cases, so defaulting to the local > (wall) TZ is OK provided you can override this consistently by adding > explicit TZ values. > > However, there is some devil in the details we need to work out. For > example, should we support both TZ names (like AEDT or Australia/Sydney) > and POSIX style +11/+11:00/+1100, should we add an option to tell org to > always add TZ info in timestamps which include time components and if > so, how complex will this need to be e.g. handle setting a future/past > timestamp which is in a different (daylight savings) offset and what > about the additional complexity in dealing with timestamp calculations > where dates might be in different offsets due to daylight savings - > while all quite possible, it does add significant complexity and this > may have adverse impact on performance. Not to say we shouldn't do it, > just that it will take significant work. > > I suspect just the first part won't have major impact - at least no more > than enforcing UTC in org-2ft. Org mode does not support TZ in time strings currently. While I would like such a feature very much, adding TZ support isn't the topic of the current bug, just fixing how time strings are interpreted. > > Tim > > P.S. when you start to think about it, it is easy to see how Java > screwed up this stuff so badly!