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

* Ihor Radchenko <yantar92@posteo.net> [2023-02-01 13:30]:
> Tim Cross <theophilusx@gmail.com> writes:
> 
> > The real question is, can the additional complexity associated with
> > including both a time zone name and an offset be justified in order to
> > handle the very small number of time stamps which will fall within the
> > daylight savings transition hour for those locations which have daylight
> > savings? Keep[ing in mind that the complexity is less to do with the
> > time stamp format and more to do with using that information in any
> > meaningful sense. This, combined with the reduced readability of such
> > time stamps and increased possibility of user confusion leads me to
> > question if allowing time stamps with both offset and time zone together
> > in the one time stamp is worthwhile. 
> 
> As I originally stated in the proposal, the real usefulness of combined
> offset+time zone is asking Org to double-check the consistency:

That is right, though that is not the fundamental reason for using UTC
offset and time zone.

Every good application should check if the time stamp is valid or
not. 

It should not allow user to specify invalid time stamps, and it should
not calculate and generate invalid time stamps.

The reason for UTC offset is future possible political changes of the
UTC offset.

It shall be assumed that time stamp from past was correct, that it was
generated by application that was using the time zone database, but
the UTC offset in present time could be changed, just as it was
mentioned for the Russian decision recently.

By using UTC offset and time zone from past, one can then use present
UTC offset definitions and calculate differences. However, there are
still rare changes with the past time zone definitions. 

Using UTC offset for future time stamps is IMHO possibly much more
problematic for the same reason of possible changes in future.

> Consider a time stamp far in future [2052-11-12 12:00+08 @!Asia/Singapore] 
> The time zone rules for Asia/Singapore may or may not remain the same
> due to political uncertainty. Today, we expect the offset to remain +08.
> If it changes in future, Org will warn the user.

Very right.

> In addition, I find specifying both the time zone and the offset
> useful for readability:

Thank you.

> Complex time zones in timestamps will not rely on user's computer having
> the up-to-date time zone database: [1916-09-12 12:00+01 @Europe/London]
> unambiguously specifies the UTC offset yet emphasizing that the
> timestamp is related to specific location (Europe/London, but not
> Europe/Paris). In fact, one may somewhat abuse this format and specify
> [1916-09-12 12:00+01 @France/Marseille] emphasizing the location.

Then if they are not to relay on time zone database, on what they can
rely as alternative?

--
Jean

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

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