Ihor Radchenko <yanta...@posteo.net> writes:
> 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) 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.
