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: Tim Cross
Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Date: Thu, 19 Jan 2023 18:23:17 +1100
User-agent: mu4e 1.9.16; emacs 29.0.60

Jean Louis <bugs@gnu.support> writes:

> * Tim Cross <theophilusx@gmail.com> [2023-01-19 00:31]:
>> The problem is with meeting 2 and the assumption there is a definitive
>> timezone for the meeting.
>> 
>> Consider this scenario. I have a meeting with two other people. We are
>> all in different timezone. What is the timezone of the meeting?
>
> Org in this state can't handle such things.
>
> A person in any timezone shall be able to see that time in his local
> time zone if we speak of distant meetings, and in case of face to face
> meetings, that person shall have computer aid to show him the meeting
> time in any time zone that user is located, during travel and upon
> arrival to face to face meeting. 
>
> User is supposed to be assisted by computer. And not to assist to
> computer, or to get troubles from computer.
>
> - Time zone shall be more or less recognizable by city and country. 
>
> - User addresses in the address book shall be part of every computer system
>
> - It is natural and common sense to know addresses of people one wants
>   to meet
>
> - By using location of person one wants to meet, computer has got
>   enough information for representation of the time zone
>
> - By sharing appointment record to user in other time zone, that user
>   would see it in his time zone, or by choice in original time zone of
>   the meeting place
>
> A record of time, shall have two attributes, the UTC time and the time
> zone to be displayed. By using system time zone setting, Org file time
> zone settings, heading time zone settings or time stamp time zone
> setting, any export of Org shall contain (by user's option) the
> desired representation of time stamps.
>
> Function of sharing of meetings shall ask local user:
>
> - is user in different time zone? 
>
> And then by choice of the user's location, the time representation
> shall be prepared in such way that both parties understand each other.
>
> That is really not in the sphere of Org where there is not even a
> decent address book available.
>
> Just re-write the time by hand for your friend at other part of the
> world, write the timestamp in his time zone and your time zone, and
> problem solved.
>
> It is supposed to be text. It is not God.

You completely misunderstood the specific issue being discussed. You
clearly have not been following this specific point being discussed and
your long reply just confuses matters rather than helps.

This issue is in dealing with the meeting time when the local timezone
changes due to daylight savings time and the fact you have two different
requirements

1. For meeting where all people are in the same timezone, a transition
in/out of daylight savings changes nothing. The meeting time stays the same

2. For meetings wiht people from different time zones, when daylight
savings transition occurs, the timestamp needs to be changed.  Nothing
needs to happen for the people in other time zones - it isn't their
problem and their meeting time is not affected.

Ihor['s suggested solution was to just use the TZ of the 'meeting', but
that is ambiguous. A meeting doesn't have a time zone and picking just
one of the recipients doens't help as now you just have the issues of
their daylight savings transitions etc.

The 'solution' is to record this meeting in UTC tz. However, to make
this 'workable' for most people, the interface for managing timestamps
needs to make this easy.

For example, I would probablyh want an interface where by default, my
timestamps have no TZ data, but if I call the command to add a timestamp
with the universal argument, it will add a default tz and allow me to
easily change it to a different one.

My default 'no tz data' choice is best for me because I don't travel
much and am rarely in different time zones. Therefore, tz data not
needed and the smaller and easier to read/edit timestamps are
preferred. If on the other hand I was someone who travelled a lot, then
I would want the default to be to add full time zone information to
timestamps (though, I would probably want an overlay or similar to
display the timestamps in a more concise format converted to current
tz).



reply via email to

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