Tim Cross <theophil...@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>
