Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis <bugs@gnu.support>]

* ypuntot <ypuntot@gmail.com> [2023-02-04 22:01]:
> Great link!
> https://spin.atomicobject.com/2016/07/06/time-zones-offsets/
> 
> "Given a local time and an offset, you can know UTC time, but you do
> not know which time zone you’re in (because multiple timezones have
> the same offset)."

Exactly.

> So, given a time zone you can know the offset (Google it, for
> example)..  Then, given the time zone and the local time, you can
> know UTC.  If orgmode gets the UTC there is not ambiguity.

Majority of people do not use UTC. Having time displayed in UTC would
and will confuse too many people, unless such time is only for logging
purposes. But Org timestamps like DEADLINE, SCHEDULE, are really meant
for a human.

Internally, in calculations, program shoulde find time time zone, UTC
offset, calculate, go to UTC, again to time zone, and again represent
proper time. And if not that way, in any case there is complexity
involved.

Here is also good reference telling people how to program and work
with time zones.

Working with Time Zones:
https://www.w3.org/TR/timezone/

> But, that would mean that the offset related to the different time
> zones must be downloaded and updated from some site.

For past timestamsp, one could store such as UTC time, and such time
may be easily represented in presen time, it may be viewable in local
time if computer program consults the time zone database. 

For timestamps we are making now, to record something, when it
happened, we could use UTC time, but only for logs and similar, not
so important time representations, which we will not revisit too often
in future.

But let us say for some future, timestamps in DEADLINE, SCHEDULED,
those timestamps related to human, the UTC offset in this case cannot
be so sure, because it is in the future, and it is vague as it could
change politically. So the future will know what will be the UTC
offset.

> As you said before, that offset can change. For example, peninsular
> Spain has the same time as Berlin, but as this doesn't make much
> sense, it could change, so updates would be necessary.

That is right.

Even the time zone designation (name) could change in future, but for that
reason, if we use today a time zone, the future time zone database
will know about time zone that (was) defined today, and computer
program will know how to calculate representation of the time in local
time in future, for the time of today.

Time zones are updated regularly, but we cannot be sure of it in case
of atomic war or other planetary commotions. ☹️ I wish people could
love each other more. ☮️

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/