Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value

[Shelby Cain]

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-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Benjamin Drung]

On Fri, 21 Sep 2012 09:25:50 -0500 Shelby Cain <alya...@hotmail.com>
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

[Aurelien Jarno]

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
aure...@aurel32.net http://www.aurel32.net

[Benjamin Drung]

Hi,

On Sun, 2023-01-08 at 16:28 +0000, alya...@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.