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

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 14/01/2023 20:50, Tim Cross wrote:
>> I"m sorry, but I don't follow. The UTC time is the only time whihc is
>> not affected by daylight savings transitions, so is the only stable
>> metric. All the others are relative to that time but can change based on
>> things like changes in DST transition dates/times. When DST transitions
>> occur, time is lost/gained wrt the local time, but real time and UTC
>> time do not change. So when DST starts here at 2am on the llth it is 5pm
>> on the 10th UTC. At 2am locally, we jump to 3am, losing an hour, but the
>> UTC time is still 5pm. The meeting I had scheduled for 10am with friends
>> form the US was at 0:00 UTC. It is now at 11am local time, but still at
>> 0:00 UTC, however, I will likely fall asleep in it because instead of my
>> normal 7 hours sleep, I only got six despite going to be and getting up
>> at the same time.
>
> Future events may be affected by changes in timezones happened after 
> scheduling them. UTC
> timestamps becomes incorrect in such cases.
>
> Let's assume that a company from Sydney has a weekly meeting on Mondays at 
> 15:00 *local*
> time. Their standard time offset is +10:00
>
> TZ="Australia/Sydney" date --date '2023-07-15 15:00' '+%F %a %T %Z %z'
> 2023-07-15 Sat 15:00:00 AEST +1000
>
> They decided to invite a person from Singapore (no DST) to join the meeting 
> online next
> year on 2024-01-15 during the period of summer (daylight saving) time (+11:00 
> offset) in
> Australia:
>
> TZ="Australia/Sydney" date --date '2024-01-15 15:00' '+%F %a %T %Z %z'
> 2024-01-15 Mon 15:00:00 AEDT +1100
>
> The person in Singapore should schedule the event at
>
> LANG=C TZ=Asia/Singapore date --date 'TZ="Australia/Sydney" 2024-01-15 15:00' 
> '+%F %a %T
> %Z %z'
> 2024-01-15 Mon 12:00:00 +08 +0800
>
> the same moment as UTC timestamp
>
> date --utc --date 'TZ="Australia/Sydney" 2024-01-15 15:00' '+%F %a %T %Z %z'
> 2024-01-15 Mon 04:00:00 UTC +0000
>
> If Australia were decided to cancel daylight saving time transition then for 
> the Singapore
> partner the meeting would be shifted by 1 hour to
>
> LANG=C TZ=Asia/Singapore date --date '2024-01-15 15:00 +1000' '+%F %a %T %Z 
> %z'
> 2024-01-15 Mon 13:00:00 +08 +0800
>
> LANG=C date --utc --date '2024-01-15 15:00 +1000' '+%F %a %T %Z %z'
> 2024-01-15 Mon 05:00:00 UTC +0000
>
> If the guest from Singapore or some guy from Australia decided to store the 
> appointment in
> UTC, not as local time, they would expect beginning of the meeting at 14:00 
> (Sydney time)
> instead of 15:00.
>
> The primary data for this event is
>
>     2024-01-15 15:00 Australia/Sydney
>
> everything else is derived accordingly to current state of timezone database 
> and should be
> recalculated in the case of its change:
>
> - AEDT +1100
> - 2024-01-15 Mon 04:00:00 UTC +0000
> - 2024-01-15 Mon 12:00:00 +08 +0800 Asia/Singapore
>
> So future events bound to local time must be stored as local time and the 
> corresponding
> local timezone. UTC must be used for global events (e.g. an eclipse) or if 
> the negotiation
> is to fix event time in UTC. UTC is not a silver bullet for time 
> computations, it should
> be used consciously.

OK, I see what your arguing now. However, I disagree on the semantics
here. Really you have the exact same issue in both use cases. Only the
way it is handled is different. For example, I actually do have a
fortnightly meeting with people in the US and my meeting time changes
due to daylight savings transition. The UTC time stays the same, but the
meeting time for me changes twice per year (moving forward/backward an
hour). Likewise, it changes for most of the other people in the meeting
who are in various timzones except for one participant in Brisbane where
they don't have daylight savings time. His meeting time is constant all
year round.

With your semantics, the person in Singapore is the one who has to keep
changing the meeting time while for the Ausies in Sydney, it stays at
15:00 regardless. Worse yet, the Singapore participant has to chnage 4
times per year - when Singapore transitions and when Sydney does.

On the other hand, the downside with my approach is that when local
daylgiht savings transition occurs, all meeting times change, including
those with only local participants, which isn't great either. Again,
this is just some of the issues I'm concerned people are glossing over
when they say it isn't too hard to add TZ support and that we can
leverage off the built-in TZ facilities of Emacs and the OS. The
underlying semantics and model is far mor complex and getting a workable
and user friendly solution which maintains the utility of the existing
timestamps is complicated and hard. The fact you can only really rely on
full timezone names e.g. Australia/Sydney and not abbreviations like
AEST makes it even worse as we run the risk of loosing the compact
format.