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

[Tim Cross]

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

No, I disagree with that statement. That is old thinking based when
meetings meant face to face meetings. Only meeting which have a specific
location can have a time zone and even then, it isn't really the
meetings time zone, but instead the time zone of the participants at the
meeting.

Meetings without a specific location do not have time zones, implicit or
otherwise. If you have an on-line meeting with 5 people from 5 different
time zones, there is no time zone which takes precedence and cna be
thought of as the meeting time zone. You could decide to do that if you
wanted, but it doesn't achieve anything useful. 

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

The issue I'm talking about has nothing to do with the other
participants of the meeting. It is irrelevant to them when my time zone
changes due to daylight savings.

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

That is a bad example and is wrong. Australia/Canberra and
Australia/Darwin are different timezones regardless. Darwin is +930 and
Canberra is +1000 (+1100 with DS). So Monday 15;00 in Darwin will be at
15:30 in Canberra outside DS time and 16:30 during DS time.

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

and this is not the issue I'm trying to solve here. At no time did I
reference booking meetings or scheduling meetings with others. This has
nothing to do with eh use case I was outlining. 

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

OK, I just give up.

I don't understand why my very simple point seems so hard for anyone to
grasp and why everyone seems so focused on the booking and scheduling of
meetings with outhers. This was never in the scope of the very simple
issue I want solved. 

All I want is for org to tell me when my meeting is. I don't care about
other people's time zones or when the meeting is for them, I don't care
who books the meeting and I don't care whether someone feels the meeting
has a time zone or not because it is all totally irrelevant for my use
case.

This is very very simple and doesn't need to be over thought.

I have two reoccurring meetings.

Meeting 1. All of the people for this meeting are in my time zone. When
daylight savings transitions occur, there is no impact. THis is how org
timestamps work now. Nothing is required.

Meeting 2. This meeting has 5 participants. They are all in different
time zones. When daylight savings time transitions occur in my timezone,
I need the time stamp to report an adjusted time based on the change
(either forward or back 1 hour). Currently, org cannot manage this and
my meeting time is out by one hour for 6 months of the year. 

How is this handled by org?

My suggested solution, which I feel is quite simple is to simply use a
timestamp with a UTC or Etc/UTC value for the time zone for meetings
with participants from different time zones and where the time of the
meeting must remain constant with respect to UTC. Assuming that once org
timestamps handling has been updated to display timestamps according to
the local time zone, the issue with the second meeting example is
solved. Thats it, done.

You might sayh this isn't a technical issue, but it can obviously be
solved adopting a technical solution.

All that remains is to work out a good interface to make it easy to set
the correct timestamp type (i.e. in local time or UTC) based on the
requirements for that meeting (which is determined by whether the
meeting has any participants in different time zones). How sophisticated
we want ot make this is undecided. My simple sugestion wa that have the
commands which insert timestamps use the universal argument - when
called with the universal argument, set the timestamp using UTC and when
it isn't, set it as it is now (or set it with the local TZ added, based
on user preference).