From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Idea for handling timezones
Date: Sun, 04 Apr 2021 08:47:35 +1000 [thread overview]
Message-ID: <87y2dz54sk.fsf@gmail.com> (raw)
In-Reply-To: <701561.1617475882@apollo2.minshall.org>
Greg Minshall <minshall@umich.edu> writes:
> Russell,
>
>> 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 wonder if this is perhaps another place where "org mode as simple
> text" conflicts with "org mode to solve difficult problems". that comes
> up from time to time (using dollar signs as delimiters for math is one
> recent example, another is "-" being "filled" into column one and taken
> as an item in a new list).
>
> it's a hard line to straddle.
>
I think you are correct. There are fairly frequent issues associated
with timestamps and much of it is due to the tension between trying to
have something which is human friendly and having something which lends
itself to being used for calculations or in an environment where the
timezone regularly changes (i.e. from someone who travels a lot).
Adding timezone infomation to timestamps by default is not difficult.
Org uses Emacs' time handling functions under the hood and supports
setting custom timestamp formats. If I was someone who regularly moved
between timezones, I would definitely modify the default format to
ensure timezone information is recorded with the timestamp. This would
at least let the user know what timezone was being referenced when the
timestamp was created and what needs to be done to (even mentally)
convert it to whatever the current timezone is.
For any calculations involving timestamps, the only sane way to do
things is to convert all timestamps to UTC, perform the calculation and
if necessary, convert back to localtime for final result. It was
mentioned elsewhere in this thread that issues associated with DST
changes are OK because they occur early in the morning and not much
happens around then. However, this ignores use cases that depend on
calculation of time intervals. Provided all calculations are performed
using UTC, everything should work as long as timestamps include TZ info.
I don't like the idea of having a header variable which records the
timezone. I think this will be a source of errors and confusion and just
won't work well for many setups (for example, people like me who have
many org files with timestamps in them).
I feel a better result would be to
- Update default timestamp format to include timezones
- Add a new function which would either (or all of)
- Convert an existing timestamp to a specified tz
- Convert all timestamps in a file to a specific tz
- Convert all timestamps in agenda files to a specific tz
- Convert all timestamps in all org files to a specific tz
User can then run the function as required (for example, after
changing timezone location).
- Ensure all exporter back ends support the ability to set an export
timestamp function, allowing changing/stripping of TZ data during export
as you frequently want a more concise format in exported documents. I
believe this is already supported to some extent.
The other things we could probably add is a timestamp display
tooltip/overlay which could be defined to popup when the mouse/cursor is
on the timestamp and which would display the timestamp in some timezone
which the user could specify as an option and which defaults to whatever
the local timezone is at the time. Then, when you see a timestamp which
is in lets say US EDT and your in Tokyo, moving your cursor or placing
your mouse on that timestamp would display a tooltip showing the local
time equivalent.
--
Tim Cross
next prev parent reply other threads:[~2021-04-03 23:26 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
2021-04-03 18:51 ` Greg Minshall
2021-04-03 20:06 ` Samuel Wales
2021-04-03 22:47 ` Tim Cross [this message]
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=87y2dz54sk.fsf@gmail.com \
--to=theophilusx@gmail.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).