On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross <theophil...@gmail.com> 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!