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.
