emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Russell Adams <RLAdams@AdamsInfoServ.Com>
To: emacs-orgmode@gnu.org
Subject: Re: Idea for handling timezones
Date: Sat, 3 Apr 2021 17:00:42 +0200	[thread overview]
Message-ID: <20210403150042.GK27597@maokai> (raw)
In-Reply-To: <647187.1617449014@apollo2.minshall.org>

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


  reply	other threads:[~2021-04-03 15:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01  7:40 Idea for handling timezones shironeko
2021-04-02 11:34 ` tomas
2021-04-03  0:36   ` Shironeko
2021-04-03  7:56     ` tomas
2021-04-03  8:03       ` shironeko
2021-04-03  8:30         ` tomas
2021-04-03  9:26           ` Shironeko
2021-04-03 11:23             ` Greg Minshall
2021-04-03 15:00               ` Russell Adams [this message]
2021-04-03 18:51                 ` Greg Minshall
2021-04-03 20:06                   ` Samuel Wales
2021-04-03 22:47                   ` Tim Cross
2021-04-04  0:51                     ` Tom Gillespie
2021-04-04 16:06                       ` Maxim Nikulin
2021-04-23  1:45                         ` Shironeko
2021-04-23  7:54                           ` tomas
2021-04-03 12:43             ` tomas
2021-04-03 12:47               ` Shironeko
2021-04-03 13:20                 ` Shironeko
2021-04-02 23:37 ` Tim Cross
2021-04-03  0:31   ` Samuel Wales
2021-04-03  0:43   ` Shironeko
2021-04-03  0:53     ` Samuel Wales
  -- strict thread matches above, loose matches on Subject: below --
2021-03-31  2:23 Shironeko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210403150042.GK27597@maokai \
    --to=rladams@adamsinfoserv.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).