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

[Tim Cross]

Jean Louis <bugs@gnu.support> writes:

> * Tim Cross <theophilusx@gmail.com> [2023-01-19 10:48]:
>> 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
>
> I do not use Org for time stamps. I am using PostgreSQL.

Then your input here is not terribly relevant IMO.


> My time
> stamps show correctly (hopefully) as I rely on the design of that
> software. I may be very wrong. Though as user I want simple thing, to
> record time, and that time has to be displayed in my time zone, and I
> want to have functions which will provide for example accounting
> statement in the time zone of the recipient in Washington, USA. As
> simple as that.
>

Completely irrelevant to the point being discussed. Yet again, you are
just pushing your beliefs and pet peeves without actually comprehending
what is being discussed. 

> There is no need for Org to deal with daylight savings, as UTC
> underlying functions are expected to deal with it. Time zone database,
> C library, I cannot know. But any error there shall go to system
> maker. Developing such complexity on Org level is not necessary.
>

Yet more indication you don't understand the issue. Nobody has suggested
that org does daylight savings calculation - in fact, the one constant
from all the issues raised in this thread is that all the time zone
calculations, conversion between time zones, calculation/conversion to
display format etc is handled by system libraries not org. 


> For Emacs it makes fun to have various calendars, but for
> international time, that has to be handled by system libraries.
>
>> 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.
>
> Sure, but that is not calculation for higher level like Org, it is for
> lower level, like system library. Discussion shall be given to
> developers of GNU C library to solve calculations with daylight
> savings. If such functions do not exist, then they can be made.
>

You still missed the point. It isn't about the calculation - where that
happens is largely irrelevant and as has been stated numerous times, org
will use the built-in Emacs interface to system facilities for this.

The issue is far more fundamental. Display the agenda with correct
meeting times regardless of daylight savings transitions. As only
meeting with participants from different timezones are affected by such
transitions, we need a way to distinguish those timestamps from
timestamps for meetings with all participants in the same time zone.

>> 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.
>
> ☺️ A meeting can have time zone. My friend, that is exactly how we do
> meetings, I have even given examples from my life on meeting
> scheduling on this mailing list. 
>

Nobody said meetings cannot have time zones. Again, work on your
comprehension. It seems you skim read then jump to the wrong
conclusion.

A meeting does NOT have a time zone. Participants in the meeting have
time zones and it is possible that every participant in the meeting is
in a different time zone. The meeting itself has no time zone.

<snipped a lot of irrelevant stuff>

>
>> 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.
>
> Then again you have to tell that it is "UTC", which means you are
> already specifying some time zone.

hence the bit where I said 

"However, to make this 'workable' for most people, the interface for
 managing timestamps needs to make this easy."

>
> You could tell that Org always thinks of UTC, but that again means UTC
> as mark, must be somewhere placed, all users must know that it is UTC,
> and again there is need for users to display time in their time zone.
>
> What do you achieve by that design? 
>

It achieves exactly the flexibility needed. As has been made clear many
many times in this thread, what we are talking about is the ability to
add time zone information, not a requirement to do so. If your use case
needs that, then org becomes more useful. If it is of no benefit in your
case, then you don't have to use it.

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. This meeting should remain at the same time
regardless of transitions in/out of daylight savings. The meeting is at
3pm every tuesday all year round.

2. A meeting timestamp for a meeting where all the participants are in
different time zones. When daylight savings transitions occur, the time
of that meeting needs to move forward/back by one hour (depending on
which transition occurs), but only forthe local participant.  Nothing
changes for the other participants and they do not need to know that the
local participants meeting time has changed.

The original question I posed is how would org distinguish between these
two timestamps and know that the second one needs to have the time
changed following a daylight savings transition and the first one does not. 

The answer is to use a timestamp in UTC timesone for the second
meeting. Note that this doesn't mean it is displayed to the user in UTC
time - it would be displayed to the user in their local time.

For org, this means everything would now work. When the user's time zone
transitions in/out of daylight savings time, timestamps with no timezone
data or in the local time zone say the same. TImestamps in UTC will
display an hour earlier/later depending on the transition and the person
will still turn up to the meeting at the correct time. 

> You will get confusion, as you are forcing majority of the world first
> to understand what is UTC.
>

That is an assumption on your part. If you had read and comprehended the
thread, you would have seen that once we identified that using the
different timestamp time zones could address the two use cases, the next
question was about how to implement this to make it easy for the
user.

For example, we could have functions specifically for booking meetings
with participants from different time zones or we could have a different
interface for booking meetings which gets additional details from the
user (such as the list of participants and their time zones) or any
number of other options which make this easy for the user and hides this
detail from them completely.


> Computers don't do that, they ask you, where are you? Athens, Greece?
> Thanks, here is your time.
>
> They don't tell you "let us keep meeting time in UTC" confusing users.
>
> Follow the decade long trend human usability trend and use time zones.
>

UTC is a time zone - just one where offset is +0000

>> 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.
>
> Time stamp does not need to have TZ data, and your function desire is
> just fine and correct.
>

No, as already explained, without TZ data, there is no way org can
distinguish the two different use cases outlined.

There have been numerous examples where TZ data in timestamps will be
extremely useful. What now needs to be clarified is

- Best interface for managing timestamps with TZ data
- Best way to deal with timestamps with tz data and export backends (for
- example, your workflow where you want exported documents to have the
  timestamps in the local time of your clients)
- Strategy for dealing with timestamps that may have different time
  zones when it comes to calculations such as duration, repeating etc,  

plus other things not yet thought of or discovered. This will be an
on-going refinement process that will expand
functionality/options. Precisely how it will evolve is not 100% clear at
this point. That will be determined by how people use it and future
feature requests.