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

[Tim Cross <theophilusx@gmail.com>]

"Thomas S. Dye" <tsd@tsdye.online> writes:

> Aloha Max,
>
> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 20/01/2023 23:09, Thomas S. Dye wrote:
>>> Max Nikulin writes:
>>> Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the
>>> conference takes place,
>>> then everyone who participates in the conference must notice this (or miss the
>>> start of the conference).
>>
>> My point is that if timestamp is stored in UTC than it becomes incorrect in the
>> case of time offset change. If such timestamp is stored as local time + time
>> zone identifier then application presenting the timestamp to users will show
>> correct time as soon as zoneinfo data is updated.
>>
>>> A virtual conference is organized by someone in Amsterdam, who sets a start
>>> time corresponding to 9AM in Amsterdam at a date some years in the future and
>>> invites participants from all over the world.  Now, if Amsterdam's timezone
>>> arbitrarily changes its relation to UTC before the conference takes place,
>>> then must everyone notice this?  Or, should Org, from the time the arbitrary change is
>>> made public, simply adjust the conference time for all the
>>> participants in the Amsterdam timezone?
>>
>> Both variants are possible and a planning application should support them. It is
>> matter of negotiation between the committee and the participants. Timestamp
>> should be stored in UTC only in one case.
>
> Agreed.  So, IIUC, there are three cases:
>
> 1) Occurrence, where the timestamp includes UTC;
> 2) Event relative to user, where the timestamp does not include UTC or a time zone; and 3)
> Event not relative to user, where the timestamp includes the relevant time zone.
>

I would argue case 2 is really just a specialisation of case 3 i.e. it
has an implicit time zone which is the user's local time zone. 

> For completeness, Case 3 might benefit from a procedure to change the relevant time zone.
> For instance, when the boss has scheduled time for you at 9:00 AM her time, but doesn't
> know where she will be on that day.
>

If it is to be a fact-to-face meeting (event), implying it therefore has
a location, you would assume your local time zone. If not face-to-face
(occurrence), it needs a UTC offset in order to ensure same point in
time for all participants. The boss either needs to specify the time
zone they are referencing the 9am to or the user will need to make a
guess, which may or may not be correct.