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

[Ihor Radchenko <yantar92@posteo.net>]

Jean Louis <bugs@gnu.support> writes:

>> It means "when I scheduled this item, I expected the UTC offset at the
>> time of the timestamp to be -08 and remain so. It was motivated by
>> America/Vancouver time zone, but if it changes in future, I do not care
>> - the scheduled time should remain at specific time point relative to
>> UTC".
>
> I read, though sorry, I do not understand who is expected to think
> that UTC offset is fixed?
>
> Is it Org as program?
>
> Or is it human?

Both.

The idea is to ensure exact point of time relative to UTC.
For example, when you want to schedule something exactly 10024 hours in
future, regardless of time zone changes.

The same can be done by specifying the timestamp in UTC directly.

> Another program in future, and human, must know did the organizer of
> event, had in mind:

I would like to remind you that timestamps are not necessarily used for
meetings. And not always shared with other people.

> I find such situations rather easy to solve with database:
>
> - I can have column like "timestamp" with UTC time or local time plus
>   UTC offset, and if I did not enter any other information, that UTC
>   offset is considered in future. Consider this column name
>   "timestamp".
>
> - I can have column "time" and when such is entered, then date is
>   extracted from "timestamp" column, and combined with time. In this
>   case UTC is only calculated in new time point but not used as period
>   from past to appointment time.
>
> - I can have time zone for the future, if I enter such in other
>   column, the future calculation must use that proper time zone. 

Sorry, I do not understand what you are trying to explain here. Would
you mind showing an example?

> You said "I do not care", that means you as human decide that 
> [2024-02-04 12:00 @-08,America/Vancouver] will use fixed -8 offset
>
> But from where in such timestamp does user or program understand that?

From syntax we are now defining, XX takes priority in @XX,YY.

> Maybe this way (hypothetically):
>
> [2024-02-04 12:00 @-08, America/Vancouver/UTC-FIXED]
>
> as that way you would give signal to program that you want UTC fixed
> time in future, and not 12:00 o'clock necessary.

I am sorry, but I don't understand what you mean by UTC-FIXED.

>> > The UTC offset is the log what was the UTC offset at the time point
>> > when timestamp was created, as future UTC offset cannot be known.
>> 
>> Sure. -08 is expected offset.
>
> If you wish to specify UTC time in future, no need to specify even any
> offset, but you can. 
>
> Look here in first example how event is defined by using UTC time:
> https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html

It is sometimes easier to define UTC time +offset instead of doing an
extra conversion in your head.

>> > Making it "fixed" does not fix it in real time, you are then
>> > introducing something new than what other programs do with time.
>> 
>> I do not understand this statement.
>
> Well to understand that, you have to make practical examples and
> understand what would human think in periods of time A, B, C, D, from
> creation of appointment, through possible changes of DST, time zone,
> UTC offset, to final appointment.
>
> Look here the second example of group-scheduled meeting that begins at
> 8:30 AM EST on March 12, 1998 and ends at 9:30 AM EST on March 12,
> 1998
> https://icalendar.org/iCalendar-RFC-5545/4-icalendar-object-examples.html
>
> DTSTART;TZID=America/New_York:19980312T083000
> DTEND;TZID=America/New_York:19980312T093000
> LOCATION:1CP Conference Room 4350

> The stuff with iCalendar works for reason that it is structured. The
> timestamp such as: DTSTART:19960918T143000Z will clearly say that time
> is specified in UTC time. No need for confusion with time zone.

> But if DTSTART has this: TZID=America/New_York:19980312T083000
>
> Then it becomes clear that it will be the UTC offset in future with
> assumed mentiond time zone.
>
> But if you mix UTC offset, plus the time zone for future, that makes
> little sense, unless you introduce some tags that timestamp is
> recognizable as using UTC time, or that it uses date/time and time

The problem being addressed with @+08,!Asia/Singapore is possible future
change in time zone. Imagine a yearly meeting you attend at
[2024-01-02 19:00 @Asia/Singapore,!+08] while living in Europe/Athens
(UTC +2). Over the years, you are used to meeting being held 13:00
@Europe/Athens time, and you do not really follow Singapore government
politics on time zones. Then, one year Singapore government decides to
switch the time zone to UTC+7. Your TZDB will get updated, but you may
still miss the meeting even though Org agenda will display the correct
new local meeting time of 14:00 @Europe/Athens. It would be useful if
Org could notify the users about such changes.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>