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

[Thomas S. Dye]

Aloha Tim,

Tim Cross <theophilusx@gmail.com> writes:

> "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. 
Case 2 covers things the user wants to do at a particular time, 
regardless of where they are and the time zone they are in.  For a 
repeating task the time zone might change from one instance to the 
next.  It needs to follow the user around and can presumably rely 
on software to keep track of that.

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

Or, it might be a recurring virtual meeting that the boss wants to 
initiate at 9:00 AM her time, regardless of the time zone she 
happens to inhabit, as might happen on a business trip.  Here, the 
virtual meeting is an event because the boss relates it to her own 
space/time.  Inconvenient for employees, but some bosses are like 
that.  Here, the time zone needs to follow the boss around.

My current hypothesis is that the three cases are exhaustive.

All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye