emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas S. Dye
Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Date: Fri, 20 Jan 2023 14:37:33 -1000
User-agent: mu4e 1.6.10; emacs 27.1

Aloha Tim,

Tim Cross <theophilusx@gmail.com> writes:

"Thomas S. Dye" <tsd@tsdye.online> writes:

Aloha Max,

Max Nikulin <manikulin@gmail.com> writes:

On 20/01/2023 23:09, Thomas S. Dye wrote:
Max Nikulin writes:
Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the
conference takes place,
then everyone who participates in the conference must notice this (or miss the
start of the conference).
My point is that if timestamp is stored in UTC than it becomes 
incorrect in the
case of time offset change. If such timestamp is stored as 
local time + time
zone identifier then application presenting the timestamp to 
users will show
correct time as soon as zoneinfo data is updated.

A virtual conference is organized by someone in Amsterdam, who sets a start time corresponding to 9AM in Amsterdam at a date some years in the future and invites participants from all over the world.  Now, if Amsterdam's timezone arbitrarily changes its relation to UTC before the conference takes place, then must everyone notice this?  Or, should Org, from the time the arbitrary change is
made public, simply adjust the conference time for all the
participants in the Amsterdam timezone?
Both variants are possible and a planning application should 
support them. It is
matter of negotiation between the committee and the 
participants. Timestamp
should be stored in UTC only in one case.
Agreed.  So, IIUC, there are three cases:

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.
I would argue case 2 is really just a specialisation of case 3 
i.e. it
has an implicit time zone which is the user's local time zone. 

Case 2 covers things the user wants to do at a particular time, regardless of where they are and the time zone they are in. For a repeating task the time zone might change from one instance to the next. It needs to follow the user around and can presumably rely on software to keep track of that.
For completeness, Case 3 might benefit from a procedure to change the relevant time zone. For instance, when the boss has scheduled time for you at 9:00 AM her time, but doesn't
know where she will be on that day.

If it is to be a fact-to-face meeting (event), implying it 
therefore has
a location, you would assume your local time zone. If not 
face-to-face
(occurrence), it needs a UTC offset in order to ensure same 
point in
time for all participants. The boss either needs to specify the 
time
zone they are referencing the 9am to or the user will need to 
make a
guess, which may or may not be correct.
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.  Here, the 
virtual meeting is an event because the boss relates it to her own 
space/time.  Inconvenient for employees, but some bosses are like 
that.  Here, the time zone needs to follow the boss around.
My current hypothesis is that the three cases are exhaustive.

All the best,
Tom

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]