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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 20/01/2023 15:11, Tim Cross wrote:
>> Max Nikulin writes:
>> 
>>> Tim, I am trying to say that any meeting either face to face or on-line may 
>>> be associated
>>> with arbitrary primary timezone.
>> and what you are saying is helpful how? In what way does what you are
>> sayhing help address my use case?
>
> Tim, are you trying to convince me that for Org it is enough to have 
> timestamps either as
> local time <2023-02-20 15:00> or as UTC something like <2023-02-20 05:00Z> 
> and ability to
> specify arbitrary timezone instead of UTC is redundant?
>

No. I have never stated anything like that. 

> I believe that in the case of support of optional arbitrary timezone in Org 
> files there is
> no point of distinction between you cases when all participants meet face to 
> face
> (<2023-02-20 15:00> or <2023-02-20 15:00@Australia/Sydney>) or it is online 
> meeting
> scheduled as <2023-02-20 09:00@Etc/UTC>.

That is all I've been saying! For meetings where everyone is in same
time zone, just use either <yyyyy-mm-dd hh:mm> OR <yyyy-mm-dd hh:ss
<local timezone>> and for meetings where there are participants from
different time zones, use <yyyy-mm-dd hh:mm ETc/UTC>. That simple.

All that remains is to figure out the best interface to make it easy for
the user to have the correct timestamp for the correct meeting type. 

>
>>> UI might offer you to choose time in your timezone and to select another 
>>> timezone for
>>> storage. For your convenience it still may be presented to you in your 
>>> local timezone even
>>> it is stored in UTC or some other one.
>> and I have said as much. So, how exactly is your contribution assisting
>> with the use case I've outlined?
>
> I had a hope to assure you that unifying the cases you are considering as 
> distinct should
> not make user experience worse.
>
> Local event and UTC is meaningful for UI to enter or adjust timestamp where 
> such cases
> should be easier to select than arbitrary timezone. For parsing, generating 
> agenda, or
> export a more abstract model can be used.

I really don't understand your continued reference to 'arbitrary
timezone' or how it is relevant. I also am not clear what you mean by
'unifying the cases'. If you mean handling the two different cases in
the same UI, that is exactly what I've been suggesting. If you mean
using the same time zone for both cases, I don't see how that could
possibly work and if you mean something else, I don't understand.

My position is very simple and very specific. Either use no TZ info or
local TZ spec for meetings where all participants are in the same TZ and
ust UTC where you have participants from different TZs. Note that htis
says nothing about how the timestamp is displayed (I would argue for
user's local time using an overlay or similar, like we do for links and
markup) and it says nothing about how the other participants record the
meeting (it is specific to the org user) and it says nothing about other
users for timestamps - only in reference to scheduled events.