<to...@tuxteam.de> writes:
> [[PGP Signed Part:Undecided]] > On Tue, Jan 31, 2023 at 11:12:00PM +0300, Jean Louis wrote: >> * Ihor Radchenko <yanta...@posteo.net> [2023-01-31 16:46]: >> > Specifying just @Europe/Berlin is ambiguous around the daylight savings >> > transition. >> >> Sorry, I cannot see practical example why is it ambiguous. Unless >> programmer does not take all information in account, it is not >> ambigous. People on this planet agree on time zones in advance, so >> there are few changes that people cannot plan in advance. > > (snipped the huge CC list) > > 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. Now that could change - for example, the German government might make a temporary or permanent change that would change the offset from UTC for that date+time the day after I look at it (or export it). Personally, I cannot see the use case of including both a fully qualitifed time zone (as in @Europe/Berlin) and an offset, but I also don't know all possible use cases - there could well be use cases where you want/need to record both the location time zone as well as the offset at the point when you recorded the timestamp. This is why I'm in favor of a flexible and extensible syntax and strongly disagree with any argument which says we don't need UTC or we don't need abbreviated TZ names or .....
