Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Tim Cross <theophilusx@gmail.com>]

tomas@tuxteam.de writes:

> [[PGP Signed Part:Undecided]]
> On Sat, Jan 14, 2023 at 03:05:22PM +0000, Ihor Radchenko wrote:
>> <tomas@tuxteam.de> writes:
>> 
>> > Now there's still enough work for the applications to do: presentation,
>> > parsing, disambiguation, if necessary asking the user for help. Someone
>> > mentioned PostgreSQL -- this is a nice example of what can be done beyond
>> > the (comparatively!) boring details of time zone management :-)
>> 
>> Do I understand correctly that PostgreSQL insists on using timestamps
>> with time zone info in favour or ordinary timestamps? Exactly to avoid
>> issues with the same timestamp pointing to a different real time from
>> epoch depending on the current OS time zone setting?
>
> It doesn't insist: it offers both data types, but the docs are very clear
> on what they prefer.
>

The internal representation of timestamps used by Postgres is ALWAYS
UTC, regardless of whether the field was defined as timestamp or
timestamp with timezone. The only real difference is that if the field
is defined as just timestamp, postgres assumes the data being entered is
in local time and will adjust using the local timezone offset. It will
ignore any tz information in the input. If the field is defined as
timestamp with time zone, it will use the offset defined by the timezone
in the input to determine the UTGC value. When displaying a timestamp,
postgres always uses the local time zone unless you request a different
timezone using the 'at time zone' construct. 

>> Thinking more about this, I can see how it can be important for
>> clocking, and similar auto-recorded information. Users may be surprised
>> to record clocking on some task yesterday just to find the clocking data
>> in future upon travelling from Singapore to San Fran.
>> 
>> So, when implementing time zones, we may need to take care about adding
>> the time zone info when auto-inserting timestamps.
>> 
>> In addition, we may provide some mechanism to set the time zone for:
>> 1. Individual files
>> 2. For all files, including possible time zone transitions over time.
>> 
>> What I mean by (2) is when the user travels from, say, Australia to USA,
>> it could be possible to say: Use Australia/Seattle up to certain time
>> and then use USA/Austin.
>> 
>> However, the above considerations are just nice-to-haves and should not
>> be a blocker to a more generic time zone support in Org. Having an
>> ability to specify time zones manually will already cater needs for a
>> number of users.
>
> Definitely. But the time stamp (with time zone) in itself doesn't
> carry enough context to actually decide that. It's even not that
> easy to wrap one's head around dates that "travel" (the easiest
> example would be perhaps: "9:00 show up at work" -- when DST takes
> effect, it's still 9:00 whatever the local time is). When you
> have appointments with people in totally diverse time zones, perhaps
> dates tend to be more fixed wrt UTC.
>

One thing to keep in mind is that the abbreviated time zone names are
really just abbreviations for time offsets. So AEST is the same as
+1000. However, full timezone names represent complete timezone rules
i.e. Australia/Sydney is not just an offset value, it can tell us (via
the tz database) when daylight savings transitions occur (both for now
and in the past). The abbreviated names lack this information and can
also be ambiguous because some countries use the same abbreviation for
inside and outside daylight savings periods.  

This means that if we were to store timestamps in org files and use the
abbreviated tz name, we cannot handle adjustments due to daylight
savings times because we don't actually know the 'real' timezone of the
timestamp - we only know the tz offset at the point when the timestamp
was created. If we really want a solution which is able to handle
mobility and movement between different timezones and adjust for changes
in offsets due to daylight savings etc, you need to record the true full
timezone name, not the abbreviation.