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>]

* Ypo <ypuntot@gmail.com> [2023-02-05 00:41]:
> I have been thinking about how I would use this feature. So use cases
> appeared, which arose some doubts about how to use this feature, and an
> opinion for the Poll surged:
> 
> If I wanted to assist to a "Mastering Emacs book club" meeting in
> America/Vancouver, while living in Spain: Doubt: Should I use local time of
> America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00
> @America/Vancouver] (I don't like space before the @, for the Poll).

The above sounds as good idea! People are in Vancouver, so it is 12
o'clock on 4th February, by using time zone "America/Vancouver".

If that time zone changes before the future even, the time zone
database is going to hold change variables, and one will still be able
to figure out the time.

> 1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. 21:00].
> (Spain local time). Correct?

Your agenda time stamp could be with Spanish time zone.

Your agenda is really this: [2024-02-04 12:00 @America/Vancouver]

And that would mean if you wish to represent it in Spanish time zone,
that computer program should:

- First read the [2024-02-04 12:00 @America/Vancouver] 

- read time zone database properties for America/Vancouver, this
  implies having latest time zone databas

- apply properties, such as possible UTC offsets, this implies
  possible changes of UTC offsets

- calculate the UTC time, at time point of reading that time

- understand local time zone, also calculate UTC time

- use above information to calculate Spanish time and representation
  in Spanish time zone

> 2. If I went on vacation to Brasília, my agenda timestamp should change to:
> [2024-02-04 do. 17:00]. (Brasília local time).

That is okay.

>    Doubt: How must the local time zone be updated to get that timestamp
> changed?

By similar formula as explained above.

> 3. Back to Spain, I see that, for political reasons, Vancouver's winter
> time-zone changed from UTC-8 to UTC-9.
>    Doubt: How would my tz database be updated?

By your system package manager and operating system maintainers. If
they do not update it, you would miss the time.

If there is any updated beyond international agreement like what is
now happening in Ukraine, I doubt you would have correct time
calculated by computer.

>    Doubt: After updating the tz database, my agenda timestamp would change
> automatically to  [2024-02-04 do. 22:00]. Correct?

Org will not know if you did update TZ database or not. That super Org
who knows how to calculate times should definitely use the TZ
database.

Time stamp would not change because you only come to some location.

But you also need to change the computer time settings (to be correct
time) and computer time zone.

If not computer time zone, then the settings for Org, as Org could
have in future settings of time zone

Once those settings are applied, your Org could show you local time.

> 4. For the Poll: What would be the expected behavior if we used the UTC
> offset?  [2024-02-04 12:00 @-08,America/Vancouver]

When time is not too far in future, it is less vague. 

When time is more far in future, it is more vague, as UTC offset could
be changed and time zone name could be changed, but TZ database would
have that information to re-calculate it in that future.

It means that UTC offset here: [2024-02-04 12:00 @-08,America/Vancouver]

is only something that is assumed, it could change, both with fact
that time zone could disappear, new time zone could appear.

TZ database would be handling those issues, that is the purpose of it.

Using UTC offset in future timestamps does not make sense as it is not
time that one can calculate in present time with certainty for reason
that future TZ database does not exist in present time.

Here is good recommendation for such case:

Time Zone Storage in Data Type "Timestamp With Time Zone" - ITCodar:
https://www.itcodar.com/sql/time-zone-storage-in-data-type-timestamp-with-time-zone.html

Booking future appointments where we want to keep the time-of-day even
if those pesky politicians change the offset of the time zone(s) in
their jurisdiction. These political changes happen surprisingly
often. So book an appointment using two columns: TIMESTAMP WITHOUT
TIME ZONE in one, and the name of the intended time zone in
another. Time zones are named with Continent/Region format such as
Africa/Tunis. At runtime, when you need a moment for calendaring,
apply the time zone to the date and time to dynamically determine a
moment according to the now-current time zone rules. In Noda Time, you
would retrieve a LocalDateTime and time zone, to produce a
ZonedDateTime for calendaring.

That means it would be better to use only date, time and time zone.

[2024-02-04 12:00 @America/Vancouver]

The TZ database is assumed to know any daylight saving time changes,
and can re-calculate it correctly in future.

There is difference with events which are not too far, and those which
are far in future.

>     - We should know beforehand the DST of Vancouver, or there would be
> warnings. It seems more difficult for the user: maybe the "-08," should be
> optional?

You cannot know it "beforehand" for future, for present time, yes, and
for some foreseeable period, it is close to certain, though depends of
the country. In some countries by knowing their political stability,
it may be very certain.

>     - Case 3: After updating the tz database we would get warnings
> too.

There need not be any warnings as smart program could figure it out
all.

Condition is only that timestamps were generated with program which
knows it well and not manually.

> To correct those warnings, should the UTC offset be changed manually
> in the timestamp?

I do not think so, and that should not be work of human.

> If there were 35 meetings in Vancouver throughout the year, to
> change all the UTC offsets could be non trivial for a normal user:
> UTC of the summer and winter would differ.

>       [2024-09-04 12:00 @-07,America/Vancouver] should be changed to
> [2024-09-04 12:00 @-08,America/Vancouver]
>       [2024-02-04 12:00 @-08,America/Vancouver] should be changed to
> [2024-02-04 12:00 @-09,America/Vancouver]

As TZ database would know that UTC offset change preceded the date and
time of 2023-02-04 12:00, that would be work of program, not human.

-- 
Jean

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

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