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

[Max Nikulin <manikulin@gmail.com>]

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.