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

* Tim Cross <theophilusx@gmail.com> [2023-02-01 12:53]:
> > Let me try to explain better. Just specifying time zone is ambiguous
> > once per year during daylight transition.
> >
> > [2023-03-29 02:30 @Europe/Berlin] is special.
> >
> > According to https://www.timeanddate.com/time/zone/germany/berlin,
> > 2023-03-29 is the time when the clock is shifted one hour back due to
> > the daylight saving transition. The wall time goes like
> >
> > 2023-03-29 02:30 -> ... -> 02:59 -> (CEST -> CET) 02:00 -> ... -> 2:30 (again!)
> >
> > So, [2023-03-29 02:30 @Europe/Berlin] can mean two time points: before
> > and after the transition. Specifying explicit offset is thus necessary
> > in this specific scenario to disambiguate the timestamp:
> >
> > [2023-03-29 02:30+2 @Europe/Berlin] (before transition)
> > [2023-03-29 02:30+1 @Europe/Berlin] (after transition)
> 
> OK, in that case, I think what we are in danger of here is letting
> the perfect be the enemy of good.
> 
> The problems of daylight savings transition points is fairly well
> understood and I think it is fairly well accepted that there is
> ambiguity arising from the use of daylight savings.

The only ambiguity is if you miss to understand that "time zone"
definition already contains specification of daylight savings.

If you do understand it, then there will be no ambiguity at all.

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

That additional complexity is important for future, as we cannot know
what will be the future UTC offset due to political changes!

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

That is very correct, that is why Org shall keep time stamps simple in
it's basic form and allow users to specify precision as they wish.

> 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 we promote Org to be good for "reproducible research" then for
those people will be of value, and many other groups who need time
precision. 

https://html.duckduckgo.com/html/?q=org+mode+reproducible


--
Jean

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

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