emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Idea for handling timezones
Date: Sat, 03 Apr 2021 10:37:22 +1100	[thread overview]
Message-ID: <87blawgrj3.fsf@gmail.com> (raw)
In-Reply-To: <EE37B08C-27C6-4270-96EA-D8546ECDD61D@tesaguri.club>

shironeko <shironeko@tesaguri.club> writes:

> Hi everyone,
> I, like many others on this list, have to move between timezones quite
> frequently. As I gathered from the archive, it seems the main complexity in
> supporting timezones is the difficulty revolving the change of timestamp format.
> So I have an idea, suppose we add a new keyword, "TIMEZONE" that can be set at
> the start of the file like so
> 	#+TIMEZONE: America/Toronto
> This specifies the timezone of all timestamps in the file. Together with it,
> there can be a function called e.g. org-shift-time, that shifts all the
> timestamp in the file to another specified timezone and updates the keyword. Of
> course, care needs to be taken when dealing with dates without time, e.g. it
> should be treated as at time 00:00 when it is alone or as the start of a time
> range, and be treated as at time 24:00 when it is the end of a time range.
> Then there could be hooks that offer to run the function automatically when it
> detects the user's system or emacs is set to a different timezone as in the file
> (e.g. when they open the file, or opens the agenda). This will make sure the
> timestamps always aligns with their current one (if they wish).

I'm sorry, but I don't like this idea. In general, I think it is the
wrong approach and not sophisticated enough to work with the
complexities associated with timestamps.

This is actually a very hard problem and not one which can be adequately
addressed with something this simple. Problems include

1. Timzone alone is not sufficient. Offsets from UTC change due to
daylight savings times etc.

2. You can easily have timestamps from different timezones in the same
org file

3. Storing timestamps in local time is problematic because of the
inherent ambiguity this can have (again, due to daylight savings times
and what occurs at the 'cut over' time).

4. Sometimes, you may want the timestamp to reflect the date/time as it
was when recorded and don't want it to 'change' because your now viewing
it in a different timezone etc.

Personally, I think timestamp 'storage' and timestamp 'display' need to
be treated separately. I also think all relevant information (timezone,
offset) need to be stored with the timestamp. I also think the
fundamental base timestamp should be stored as UTC, allowing all time
calculations to be consistent (free of daylight savings time changes).
The user can then manage how the value is displayed by setting timezone
and offsets as appropriate (with perhaps the default being the local
system settings or whatever offset/tz was stored with the timestamp

It is very difficult to predict or understand all the use cases for
timestamps. Therefore, any scheme must be extremely flexible. Experience
has taught me that one critical component is that at the lowest level,
many problems are avoided if the value is in UTC. Problem is, UTC is not
terribly human friendly. Luckily, this can largely be automated for many
common use cases. Unfortunately, it does also mean that if you are
someone who frequently moves between many timezones, your situation will
be more complicated. 

ne of the most frustrating parts of working with timestamps is daylight
saving times. This causes complications at so many levels. In
particular, I hate the fact change over dates often change and more
often than not, those changes are based around politics and at the whim
of politicians, which makes programatic handling more complex than it
needs to be.

Tim Cross

  parent reply	other threads:[~2021-04-03  0:07 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
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 [this message]
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=87blawgrj3.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \


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