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

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

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

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