Hi, On Sun, 2023-01-08 at 16:28 +0000, alyan...@hotmail.com wrote: > January 6, 2023 2:33 PM, "Benjamin Drung" <bdr...@debian.org> wrote: > > > > > It tend to prefer option one (for consistency), but I can see that users > > might find option two easier for them. > > > > -- > > Benjamin Drung > > Debian & Ubuntu Developer > > It is certainly a confusing UX but I’ve long since given up fighting it and > use American/Chicago (or whatever the city name based timezone is) as the > timezone. > > However, I can state (as an American) that if I walk up to someone on the > street and ask them what timezone we are in they are going to reply Central, > Mountain, Eastern, Pacific, etc and not Chicago, Denver, New York, Los > Angeles, etc. It's just not a way people think about timezones here vs the > rest of the world I suppose? > > Regardless, the real confusion has always been that tzdata package updates > aren't changing anything about the America/*, US/* timezones so why is it > touching my /etc/timezone at all? As a developer in a previous life, I > assume some sort of call to is being made to a validation function that is > resolving the symlink based path to the real path? > > For what it is worth, I do generally prefer consistency as well.
So for an easy solution, I will change debian/tzdata.config to not change the US/* timezones to their America/* counterparts. Maybe in the long run we might change from selecting area -> city to area -> country -> location (in your case: Americas -> United States -> Central (most areas)), but this kind of selection has its own kind of problems that need to be resolved. -- Benjamin Drung Debian & Ubuntu Developer