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.
