emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tom Gillespie <tgbugs@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Idea for handling timezones
Date: Sat, 3 Apr 2021 17:51:17 -0700	[thread overview]
Message-ID: <CA+G3_PN5x6wsrw7FM0RV06=6FbUMoaZryKZxxg4tvc_bAgCP=Q@mail.gmail.com> (raw)
In-Reply-To: <87y2dz54sk.fsf@gmail.com>

Time zones are tricky, but there are some requirements that make it
possible to rule out many apparent solutions because they violate some
critical invariant. For example. Timezone cannot be scoped to the
file. This is because many users (myself included) have a single org
file that is used in and across multiple timezones. Thus the original
proposal in this thread to have a #+timezone: keyword is insufficient
for many use cases, and can lead to significant confusion and bad

Similarly it is probably a bad idea to always use UTC because even
though it will technically always be correct (while on Earth ...), it
means that the user will need to have kept track of their spatial
coordinates in addition, and in addition there will be an eternal
dependency on the timezone database in order to correctly reconstruct
what the timezone would have been. All in all it is better to assume
that the user has correctly configured their clock for their needs,
and record the timestamp with timezone offset (NOTE textual timezones
cannot be used in timestamps for a variety of reasons not the least of
which is that they are ambiguous, see CST for example). Sadly, the
ISO8601 timestamp specification for a negative timezone offset uses a
hyphen minus, the same as the date separator, so that baggage is going
to be with us for the rest of time (at least until someone comes up
with something better than ISO8601), but at least it requires no
additional information to capture all the information needed to
correctly reconstruct the time that it stamped.

Finding a timestamp format that has a regular grammar, is invariant to
changes in the location and time of the user (What if the user is on
Mars? What happens after year 9999? What happens if someone needs to
reference a date in the far future? What if someone wants to mention a
historical date e.g. 1000BCE?), doesn't require external information,
and is also somewhat human readable, is a major challenge. If we could
serialize something like the unix epoch into a file and render it
differently in the buffer that might work, however that defeats one of
the major points of using org as a plain text format.

My proposal at the moment based on the constraints imposed by the
current timestamp format that includes the repeat or delay syntax
would be the following (date and time and day are separated by a

date: ([+-][0-9]\+|[0-9]{4})(-[0-9]{2}){2}
time: ([0-9]{2}:[0-9]{2}(:[0-9]{2}(,[0-9]{1,9})?)?[+-][0-9]{2}:[0-9]{2})?
day: ([a-zA-Z0-9]\+)?

followed by a space and then the repeat or delay for example
[+10000-01-01 10:11:00,992315771-04:00 Sat] or
[-480-08-20 05:00+01:00]
or more temporally local
[2021-03-03 17:43-07:00 Sat]

This is the closest I have been able to get while working through
formalizing all of org syntax and trying to come up with more robust
solutions for timestamps.
For comparison see org-ts-regex and friends in org.el. I have also not
come up with a better solution for the repeat or delay syntax, though
ISO8601 interval
specification might be an option. Similarly there are extensions for
dealing with uncertain dates and times, but I don't have good
proposals for those right now,
and the use cases are also somewhat out of scope.


  reply	other threads:[~2021-04-04  0:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01  7:40 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
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 [this message]
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:

  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='CA+G3_PN5x6wsrw7FM0RV06=6FbUMoaZryKZxxg4tvc_bAgCP=Q@mail.gmail.com' \
    --to=tgbugs@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \


* 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


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).