From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Cross 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: Thu, 02 Nov 2017 00:09:03 +1100 Message-ID: <87shdykuxc.fsf@gmail.com> References: <87bmknkwhe.fsf@nicolasgoaziou.fr> <87tvyfjgjk.fsf@nicolasgoaziou.fr> <87tvyelb60.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9slf-0007IP-8F for emacs-orgmode@gnu.org; Wed, 01 Nov 2017 09:09:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9sla-0007rx-RJ for emacs-orgmode@gnu.org; Wed, 01 Nov 2017 09:09:15 -0400 Received: from mail-pg0-x22c.google.com ([2607:f8b0:400e:c05::22c]:52286) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e9sla-0007rm-Ib for emacs-orgmode@gnu.org; Wed, 01 Nov 2017 09:09:10 -0400 Received: by mail-pg0-x22c.google.com with SMTP id a192so2071940pge.9 for ; Wed, 01 Nov 2017 06:09:10 -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: Allen Li Cc: emacs-orgmode@gnu.org, Nicolas Goaziou Allen Li writes: > 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 disagree. The root cause of the bug is due to a lack of clarity regarding timezones. I also suspect this is also the basic cause of issues relating to the use of timestamps/time strings and daylight savings, especially when it comes to performing calculations etc. > 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> Org mode refers to what you are calling time strings as timestamps. In reality, there is no difference - one is just a numeric representation and the other is a string representation. It is good you have clarified your definition to reduce confusion. However, I think the problems are arising because of a lack of explicit TZ handling. > > 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. > A point in time is measured in number of seconds since epoch. However, if you want to use local (wall) time to display that point, you have to include TZ information when converting that number to a more meaningful/usable (for humans) format. The point 'now' for me is UTC+1100 and for you (based on your previous post) UTC-0700, so our representations in string format of this value will be different. Even on a single machine, it is also relevant. For example, if I have two org timestamps (your times strings) and I want to calculate the number of hours between the two, I need to include TZ information as one timestamp might be during daylight savings time and the other outside daylight savings time. Any calculation which fails to consider TZ information in this case will be out by an hour. If we just take the simple solution and ignore TZ information, we will break calculations which cross daylight savings 'boarders'. I also suspect we will get inconsistent behaviour when integrating with other systems (such as external calendars, ical integration or sharing timestamp data with others etc). >> 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. > We could make the decision that all org timestamps are relative to the local TZ (ignoring the daylight savings issue) and that would probably be OK for most users, but I feel the whole issue is due to a lack of adequate/consistent TZ interpretation. The problem with org-2ft is that it forces the conversion into UTC when the input time string may actually be in local time, resulting in a number which is out by whatever the local offset is. When you then convert back, your string representation will be out by at least that amount (possibly more depending on whether TZ info is applied in the conversion back to a string). If it wasn't for the benefits of org files being essentially plain text files, the easiest solution would possibly be to represent timestamps as a number and use an overlay or similar to convert it to a human readable value based on whatever the user sets as the timezone for display/export. Unfortunately, this breaks one of the big benefits of org-mode over other solutions i.e. the data is just plain text and can be accessed/used by anything able to read plain text. Tim >> >> Tim >> >> P.S. when you start to think about it, it is easy to see how Java >> screwed up this stuff so badly! -- Tim Cross