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 Tim,
> >
> > Tim Cross <theophilusx@gmail.com> writes:
> >
> > > "Thomas S. Dye" <tsd@tsdye.online> writes:
> > >
> > > > Aloha Tim,
> > > >
> > > > > UTC is a time zone - just one where offset is +0000
> > > > UTC is absolute time.  It lacks the spatial component that 
> > > > defines a time zone.
> > > Really? I would have thought the prime meridian was the 
> > > spacial
> > > component for UTC? I thought the full long time zone name was 
> > > Etc/UTC
> > > and UTC as the abbreviation.
> > >
> > > Regardless, in all the libraries I've used, you can use 
> > > Etc/UTC or UTC
> > > in exactly the same way you would use something like 
> > > Australia/Sydney or
> > > AEST. So perhaps, from a pedantic standpoint, it is not a time 
> > > zone, but
> > > for all intent and purpose in this discussion, I feel that 
> > > point is
> > > irrelevant.
> > Agreed.  It does seem irrelevant for time zone libraries.
> >
> > Nevertheless, from the Org perspective it might not be.  An 
> > occurrence, which marks
> > changes in the nature or relations of things at a time, 
> > requires absolute time.  Meetings,
> > which involve a change in relation among participants, are 
> > occurrences.  IMO, this
> > indicates Org should give occurrences a UTC timestamp, then 
> > translate that for each of the
> > participants using their local time zone.  The insane interval 
> > problems that Ihor brought
> > up are moot in absolute time.  A single timestamp serves a 
> > meeting regardless of whether
> > the participants are all in one time zone or spread around the 
> > globe.
> > An occurrence contrasts with an event, which is tied to the 
> > user's space/time.  Time here
> > is relative to the user.  IMO, this means that Org should give 
> > events a timestamp without
> > reference to either absolute time or a particular time zone, 
> > like the one it uses now.
> Just checking if I understand. I think we are coming from the 
> same
> position and with the same conclusion.
Thanks!

> In the situation where the meeting involves people from 
> different time
> zones, the time of the meeting as reported by org needs to be 
> adjusted
> after a daylight savings transition so that the time maintains 
> the same
> relative to UTC. i.e. meeting time reported in local time goes
> forward/backward 1 hour depending on the daylight savings 
> transition
> (in/out). I guess this is what you call an occurrence? 
>
> When all participants in a meeting are in the same time zone, 
> you do not
> want the time changed as the result of the daylight savings 
> transition.
> This is what you call an event?
Every meeting is an occurrence because it involves changes in 
relations of things at time; in this case meeting participants 
relate to one another via Jitsi, regardless of whether they are 
all in one time zone or spread over the globe.
An event's time is relative to the user's location, or space/time. 
So, the example I gave earlier "Brush teeth before bed" set to 
10:00 PM, which works whether I am home in Honolulu or enjoying 
the hustle and bustle of Manhattan, is a simple event.  It happens 
at that time in the timezone I happen to inhabit at the moment, 
because I intend to go to sleep shortly after 10:00 PM regardless 
of where I am.
> So, using your terminology, what we now need is convenience 
> functions
> for setting an occurrence timestamp and an event timestamp. I'm 
> not sure
> if occurrence/event are the best terms, but I cannot think of 
> better
> ones. Just slightly concerned people will have trouble grasping 
> the
> difference and undersanding why some meetings are an occurrence 
> while
> others are an event. FOr the user, they are just meetings.    
Yes, both meetings are occurrences.

I agree that the terms take some getting used to.  I got them from 
Frank Ramsey, who seemed to be happy with event, but not so happy 
with occurrence.
The difference is this: Will the happening being scheduled involve 
other people, who will share the Org timestamp, or will it take 
place at the same absolute time, regardless of where you are when 
it happens?  If so, then the timestamp should be stored as UTC (it 
is an occurrence that requires absolute time).
Or, is it something you want to do at a time, regardless of where 
you are.  If so, then the usual Org timestamp without UTC is what 
should be stored (it is an event that requires time local to the 
user).
In the case of a meeting, where the one who calls the meeting 
sends an Org file with a meeting agenda and a UTC timestamp to 
each of the participants, Org will translate the UTC timestamp 
into local time for each participant.  Similarly, when you are 
traveling, Org will translate the UTC timestamp to the timezone 
you happen to inhabit.  Here, I'm assuming that the timezone 
machinery is capable of determining local time relative to UTC.
hth,
Tom

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