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 rlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3