Re: Idea for handling timezones

[Tim Cross]

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

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