Aloha Max,
Max Nikulin <maniku...@gmail.com> writes:
On 21/01/2023 07:37, Thomas S. Dye wrote:
1) Occurrence, where the timestamp includes UTC;
2) Event relative to user, where the timestamp does not
include UTC or a
time zone; and 3)
Event not relative to user, where the timestamp includes the
relevant time
zone.
For a while I prefer to concentrate on future timestamps and
postpone discussion
of ones in the past.
I'm curious to find out how the distinction between past and
future makes a difference.
As to format for storage timestamps in Org files, particular
timestamps may have
or not explicitly specified timezones, but it is unrelated to
these 3 cases.
I'm curious to learn the classification unrelated to these three
cases used to determine when to store UTC and timezone.
It
may be convenient to keep work.org file with TIMEZONE keyword
for location of
the office and do not specify it for each timestamps, so during
a trip it allows
to see correct time of regular meetings. In addition you may
have personal.org
file where most timestamps assumes timezone of your current
presence. In both
files some timestamps may have explicit timezone either "local
follow me", UTC,
or for particular location.
From my point of view these, 3 cases might be relevant to
date-time picker UI,
but not for storage format. While parsing, interpretation of
each timestamp
without explicit timezone depends on preferences chosen at
higher scope.
I'm curious what these preferences are, or might be.
Or, it might be a recurring virtual meeting that the boss wants
to initiate at
9:00 AM her time, regardless of the time zone she happens to
inhabit, as might
happen on a business trip.
I believe that some manual action is required in this case
anyway. You almost
certainly already have 9:00 AM in your agenda as a reoccurring
timestamp either
with implicit or explicit timezone of usual presence. For the
period of the trip
it is necessary to add series of meetings with explicitly
specified timezones
(UTC or locations during the trip). Another approach is to
define ad hoc "boss"
timezone and update it to reflect all trips.
Agreed. The boss needs to inform you what her local time will be
for the meeting by sending you a timestamp with a time zone.
Ideally, Org would know how to associate the timestamp with a
recurring item stored locally.
At the Org side it might be support of multiple ad hoc
"timezones": a one for
you personal trips and several ones for people you frequently
communicate with.
It is a nice option, but might be too complicated for usage. It
may be easier to
suspend regular entry and to add custom ones with no
requirements related to the
code. Anyway it assumes some communication between participants.
Nowadays, I am frequently asked by applications to give permission
for using my location. When I give it, the application reports
back with my local postal code, etc. I'm assuming Org can use
location to determine my current timezone.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
