tzdata update keeps changing my timezone

Bug #772024 reported by pi-rho on 2011-04-27
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tzdata (Debian)
tzdata (Ubuntu)

Bug Description

Binary package hint: tzdata

Other than the fact that Chicago, Illinois is in US Central Timezone, I have no relationship to Chicago. I am not in Chicago. I do not want to be in Chicago. I am in the Central Timezone. I am physically closer to other cities mentioned in tzdata. Selecting America/Chicago versus US/Central is not easier for me nor is it more intuitive. I understand that the upstream tzdata package goes a long way in documenting all of the weirdness associated with timezones and different localities' treatment of timezones and daylight "savings" time. However, from an end-user perspective, the distribution should place no special importance or preference on one timezone specification or another. Likewise, if a user chooses a timezone, the system should never change it.

To reproduce the issue:

# Manually select US/Central
me@ubuntu:~$ sudo dpkg-reconfigure tzdata
[sudo] password for me:

Current default time zone: 'US/Central'
Local time is now: Wed Apr 27 16:05:02 CDT 2011.
Universal Time is now: Wed Apr 27 21:05:02 UTC 2011.

# Validation that selection was accepted
me@ubuntu:~$ cat /etc/timezone

me@ubuntu:~$ md5sum /etc/localtime /usr/share/zoneinfo/US/Central
6540624294b1193e22ed7a15692f2de7 /etc/localtime
6540624294b1193e22ed7a15692f2de7 /usr/share/zoneinfo/US/Central

me@ubuntu:~$ debconf-show tzdata
debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied
* tzdata/Zones/US: Central
* tzdata/Zones/Etc: UTC
* tzdata/Zones/America: Chicago
* tzdata/Areas: US

# Force the package to reinstall
me@ubuntu:~$ aptitude reinstall tzdata
The following packages will be REINSTALLED:
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/658 kB of archives. After unpacking 0 B will be used.
Preconfiguring packages ...
(Reading database ... 168356 files and directories currently installed.)
Preparing to replace tzdata 2011g-0ubuntu0.11.04 (using .../tzdata_2011g-0ubuntu0.11.04_all.deb) ...
Unpacking replacement tzdata ...
Setting up tzdata (2011g-0ubuntu0.11.04) ...

Current default time zone: 'America/Chicago'
Local time is now: Wed Apr 27 16:05:22 CDT 2011.
Universal Time is now: Wed Apr 27 21:05:22 UTC 2011.
Run 'dpkg-reconfigure tzdata' if you wish to change it.

# Now previous indicators are reset to America/Chicago instead of US/Central

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: tzdata 2011g-0ubuntu0.11.04
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic
Uname: Linux 2.6.38-8-generic x86_64
Architecture: amd64
Date: Wed Apr 27 15:54:33 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
PackageArchitecture: all
 PATH=(custom, user)
SourcePackage: tzdata
UpgradeStatus: Upgraded to natty on 2011-04-10 (17 days ago)

Related branches

pi-rho (pi-rho) wrote :
pi-rho (pi-rho) wrote :

Same behavior: tzdata_2011g-0ubuntu0.11.04_all.deb

Prayag Narula (prayag) wrote :

Same behavior: 2011g-0ubuntu0.10.04_all.deb
Also, it breaks my system clock which keeps jumping to 2 hours ahead.

Changed in tzdata (Debian):
status: Unknown → New
Micah Gersten (micahg) wrote :

Thank you for your bug report. This bug has been upstreamed to Debian. You can track it and make comments at:
Please report any other issues you may find.

Changed in tzdata (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Shelby Cain (alyandon) wrote :

Is there any way we could see about having this package patched by an Ubuntu maintainer?

Based on reading over the open bugs associated with tzdata on Debian's bug tracker, this report and several other reports for the same undesirable behavior have languished from anywhere from 6 months to several years without a single response from the maintainer(s).

I don't know if that indicates a lack of concern about the issue or that the package itself isn't being actively maintained beyond database updates but in either case it seems to me that a user shouldn't have to constantly reset /etc/timezone in order to prevent it from being updated to a technically correct although undesirable value.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.