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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

>> Either I understand you wrong, or you don't know what you are
>> talking about. 2023-03-23 02:30 @Europe/Berlin refers to /two/
>> points in time, thus it /is/ ambiguous. If you use disambiguating
>> "time zones" (MEZ vs MESZ in this case) you can resolve that.
>
> I think the confusion relates to context interpretation. If you see
> @Europe/Berlin in isolation, then it is ambiguous as it can refer to two
> different time zone definitions (standard v daylight savings).  However,
> if you consider it in conjunction with a date and time, as in 2023-03-23
> 02:30 @Europe/Berlin, then it isn't ambiguous - in that case, it really
> just says 'Lookup the time zone offset in the databse for Berlin as of
> that date and time.
>...
> Personally, I cannot see the use case of including both a fully
> qualitifed time zone (as in @Europe/Berlin) and an offset...

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)

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