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

["Thomas S. Dye" <tsd@tsdye.online>]

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 03:09, Tim Cross wrote:
>> To reiterate for the last time, there are 2 clear and different 
>> use
>> cases for timestamps associated with meetings.
>> 1. A meeting timestamp for a meeting where all the participants 
>> are in
>> the same time zone.
> ...> 2. A meeting timestamp for a meeting where all the 
> participants are in
>> different time zones....
>
> Tim, every scheduled meeting event is associated with some 
> particular time zone,
> often implicitly. So it is single use case.
>
> It is up to participants to negotiate which timezone is the 
> primary one for each
> event. It is matter of people communication, not technical 
> issue.
>
> First Monday 15:00 is (almost) equally precise for
> - Australia/Canberra having DST
> - Australia/Darwin where currently no DST
> - +1000 (the highest chance of improper use unfortunately)
> - UTC
>
> Aside from time transition intervals, it is possible to take any 
> of this variant
> and to present time local for other participant across the 
> globe.
>
> Storage timezone may differ from the current user preference 
> which time zone
> should be used to display timestamp or to export it.
>
> The problem arises when several participants believe that their 
> timezones are
> primary ones and they do not sync their schedules through a 
> shared file or a DB
> entry. An application can not solve this problem, but it might 
> try to help to
> identify it. Some efforts are necessary from user side. 
> Timestamp should contain
> list of timezones of other participants and cached local time. 
> In such case an
> application may warn users that local time values become 
> inconsistent due to DST
> transitions or due to update of time zone database. Unsure to 
> what degree it
> should be implemented in Org.
>
> So
> - It is participants fault if a meeting is not associated with 
> particular
>  timezone
> - Having a fair time handling library, it does not matter what 
> time zone is used
>  to schedule the meeting.

Or, one can recognize that the meeting is an occurrence that 
requires absolute time and a timestamp with UTC.  Each participant 
will resolve UTC to the local time where they happen to be when 
the meeting takes place.  The user might toggle between UTC and 
the local time translation using overlays, like pretty entities. 
This avoids the problem of negotiating a timezone caused by 
forcing an occurrence to be represented as an event relative to a 
fictitious space/time.

hth,
Tom

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