Re: Idea for handling timezones

[Russell Adams <RLAdams@AdamsInfoServ.Com>]

On Sat, Apr 03, 2021 at 02:23:34PM +0300, Greg Minshall wrote:
> > #+TIMEZONE: America/Toronto
> >
> > at the start of their org file, and they moved to Shanghai, all the timestamp in
> > the org file is converted using something equivalent to

I think what you're saying here is that timestamps without timezone
information should have a default timezone. I'd suggest there is a
global default setting (ie: init file), and allow a buffer local
override. Essentially all timestamps that don't specify a timezone
should fall back to the local TZ, unless there's a buffer override.

I'd be in favor of revisiting the idea of putting timezone information
into the timestamp. I know it's a deep change, but this is a kind of
incremental growth we should expect to a core feature. I frequently
fight this issue myself with meetings across timezones.

I would not suggest using UTC. I believe one of the reasons timestamps
didn't include TZ information was to keep them short and human
legible. Solutions with overlays to change a timestamp reduce the
usefulness of the plain text reading of Org (ie: less, grep,
etc). Storing timestamps with UTC is really a shortcut for the
computer, not the user.

I was just reading about Emacs' parse-time-string function, and Emacs
already has TZ conversion built in to many of the time functions. It
seems to me that we could fall back to the Emacs parser if needed.

https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Parsing.html

Today's timestamps are in the form of "YYYY-MM-DD Day HH:MM". I've
often wondered that the day name is in there, other than for human
legibility. Given timestamps are always wrapped in <> or [], for
active and inactive timestamps accordingly, parsing for a new element
at the end by time zone name doesn't sound so bad.

Staying with user friendly, I think time zone names would be more
useful than delta syntax from UTC. [2021-04-03 Sat 16:56 CEST] doesn't
sound too bad, given the timezones aren't expected to be in every
timestamp.

I really think that the key issue making adoption difficult will be
all the tooling reading these, not the timestamps themselves.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3