Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value
Hi, On Sun, 2023-01-08 at 16:28 +, alyan...@hotmail.com wrote: > January 6, 2023 2:33 PM, "Benjamin Drung" 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
Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value
January 6, 2023 2:33 PM, "Benjamin Drung" 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. Shelby
Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value
On 2023-01-06 20:33, Benjamin Drung wrote: > On Fri, 21 Sep 2012 09:25:50 -0500 Shelby Cain > wrote: > > Package: tzdata > > Version: 2012e-0ubuntu0.12.04.1 > > Severity: important > > > > Every time an update to the tzdata package is published, it results in > my /etc/timezone being reset from > > "US/Central" to "America/Chicago". While technically America/Chicago > is indeed the same timezone, it is > > unintuitive to say the least considering the fact that I live 929 > miles (~1500 km) from Chicago, Illinois. > > There are symlinks in /usr/share/zoneinfo for backward compatibility. > US/Central is a symlink pointing to America/Chicago. > > The Debian package updates some of those backward compatible symlinks to > their new targets (see convert_timezone in debian/tzdata.config). This > is useful for changes like renaming Kiev to Kyiv. These timezones that > are updated are not presented as option in debconf – except for the > symlinks in US. This is inconsistent and needs to be fixed. > > So there are two possible solution: > > 1. Drop the US area from the debconf template. Then only continents and > oceans remain as areas. This would be more consistent. > > 2. Drop the US/* timezones from convert_timezone. > > It tend to prefer option one (for consistency), but I can see that users > might find option two easier for them. From a maintainer point of view (consistency), and also from a European point of view, the first option looks the best. But I think US users are used to timezones and not cities to select their timezones, so option 2 is probably the best here, even if considered as deprecated upstream. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value
On Fri, 21 Sep 2012 09:25:50 -0500 Shelby Cain wrote: > Package: tzdata > Version: 2012e-0ubuntu0.12.04.1 > Severity: important > > Every time an update to the tzdata package is published, it results in my /etc/timezone being reset from > "US/Central" to "America/Chicago". While technically America/Chicago is indeed the same timezone, it is > unintuitive to say the least considering the fact that I live 929 miles (~1500 km) from Chicago, Illinois. There are symlinks in /usr/share/zoneinfo for backward compatibility. US/Central is a symlink pointing to America/Chicago. The Debian package updates some of those backward compatible symlinks to their new targets (see convert_timezone in debian/tzdata.config). This is useful for changes like renaming Kiev to Kyiv. These timezones that are updated are not presented as option in debconf – except for the symlinks in US. This is inconsistent and needs to be fixed. So there are two possible solution: 1. Drop the US area from the debconf template. Then only continents and oceans remain as areas. This would be more consistent. 2. Drop the US/* timezones from convert_timezone. 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
Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value
Package: tzdata Version: 2012e-0ubuntu0.12.04.1 Severity: important Dear Maintainer, Every time an update to the tzdata package is published, it results in my /etc/timezone being reset from US/Central to America/Chicago. While technically America/Chicago is indeed the same timezone, it is unintuitive to say the least considering the fact that I live 929 miles (~1500 km) from Chicago, Illinois. Despite me generating this report against an Ubuntu specific package, the behavior is present in the current tzdata package in Debian 6.0.5. I'd like to suggest that tzdata package updates should not overwrite /etc/timezone unless there is a *critical* need to do so. Steps to reproduce: 1) Execute dpkg-reconfigure tzdata and set timezone to US/Central 2) Verify that /etc/timezone contains US/Central 3) Force reinstall of tzdata via aptitude reinstall tzdata (or wait until a regular tzdata update is published) 4) Notice that dpkg-reconfigure informs you that the default timezone America/Chicago has been selected and helpfully suggests running dpkg-reconfigure tzdata if a different timezone is desired. 5) Verify that /etc/timezone now contains America/Chicago I can't help but notice that this issue has been around for quite some time and has resulted in at least one pretty humurous bug report filed against a downstream distribution: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/772024 However, despite that downstream bug report being over a year old and an open Debian bug that seems to describe the issue being over two years old there seems to have been no movement on the issue. I'm going to assume that part of the problem is that the downstream bug report was never properly introduced into the Debian bugtracking system and that the necessary information didn't exist where a Debian maintainer could easily reproduce and fix the underlying issue. Hopefully, the steps I've outlined above will help solve that part of the problem. Please let me know if there is anything else that I can do to assist. Shelby Cain -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise'), (100, 'precise-backports') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-30-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.42ubuntu1 tzdata recommends no packages. tzdata suggests no packages. -- debconf information: tzdata/Zones/Australia: * tzdata/Zones/US: Central tzdata/Zones/Asia: * tzdata/Zones/Etc: UTC tzdata/Zones/SystemV: tzdata/Zones/Arctic: tzdata/Zones/Pacific: tzdata/Zones/Antarctica: tzdata/Zones/Europe: tzdata/Zones/Africa: * tzdata/Zones/America: Chicago * tzdata/Areas: US tzdata/Zones/Atlantic: tzdata/Zones/Indian: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
