Aloha Max,
Max Nikulin <maniku...@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
