From: Samuel Wales <firstname.lastname@example.org>
To: Tim Cross <email@example.com>
Subject: Re: Idea for handling timezones
Date: Fri, 2 Apr 2021 17:31:28 -0700 [thread overview]
Message-ID: <CAJcAo8v-sVGWpi=TyDjLDUdwYk-2cOb4Lem2nbxF-KjKYQnLxg@mail.gmail.com> (raw)
org has capability of overlaying [or similar] tses with user-defined
something or other. for locale type purposes.
perhaps, in principle, all tses for users who need tz could be in utc
or similar, and such overlays could be used to localize on the fly?
On 4/2/21, Tim Cross <firstname.lastname@example.org> wrote:
> shironeko <email@example.com> 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
>> supporting timezones is the difficulty revolving the change of timestamp
>> 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
>> 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.
>> should be treated as at time 00:00 when it is alone or as the start of a
>> range, and be treated as at time 24:00 when it is the end of a time
>> 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
>> 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
The Kafka Pandemic
Please learn what misopathy is.
next prev parent reply other threads:[~2021-04-03 0:33 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
2021-04-03 0:31 ` Samuel Wales [this message]
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
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 \
* 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).