Installer sets wrong timezone

Bug #246732 reported by Vladimir Sizikov
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
tzdata (Ubuntu)
Expired
Undecided
Unassigned
Nominated for Hardy by Vladimir Sizikov

Bug Description

Binary package hint: tzdata

During installation of Ubuntu 8.04, or later during 'sudo dpkg-reconfigure tzdata', when user selects America/New_York, or America/Los_Angeles or America/Chicago, *wrong* /etc/localtime is created.

That file contains EST5EDT or PST8PDT settings, not the proper ones.

And, due to this, JDK reports wrong default time zone out of java.util.TimeZone.getDefault.getID, it reports something like "SystemV/PST8PDT", which is outdated and incorrect.

On properly configured systems, the localtime file should contain data of *modern* timezones, not the legacy ones.

This issue affects Joda Time Java library, JRuby and any other users of time/timezone functionality of JDK.

P.P. This is a regression, since Ubuntu 7.10 was working correctly.

P.P.S. Once I replace /ete/localtime with proper America/New_York file, everything gets back to normal.

Revision history for this message
Vladimir Sizikov (vsizikov) wrote :
Revision history for this message
Adam Feuer (adamf-pobox) wrote :

Here is a workaround that worked for me:

sudo cp /usr/share/zoneinfo/right/America/Los_Angeles /etc/localtime

(replace America/LosAngeles with your time zone.)

Revision history for this message
Dawie Steynfaard (dawies) wrote :

What happened:

During a new installation of Ubuntu 9.04 from a live CD downloaded from a local mirror server, the modem was set to a local-only internet account, costing about 15% of international bandwidth. The installer came up with a world map from which the time zone was selected. The time shown was 2 hours ahead of the current time and could not be edited. During the installation, the computer clock was advanced by 2 hours. This was rectified manually after the installation.

After 2 weeks of exposure to local and international time servers, the system software clock still has this built in error of 2 hours, caused by the wrong time zone during installation. The attached screenshot file shows the directory listing of some system folders of a computer booted at 06h00 SAST. Some has the correct time, while others are time-stamped 2 hours into the future.

What should have happened:

The installer should not be allowed to change the computer clock. It should calculate the universal time from the computer clock, and the time zone chosen by the user. The time zone need not be chosen graphically. A simple drop-down list showing the time zones with a few cities is good enough. All users know in which time zone they are. In my opinion, this bug is also the cause of most of the other time-related bugs reported.

Revision history for this message
Snowflake (obsidianfoundry-snowflake) wrote :

/etc/localtime should be a *symlink* to (for example) /usr/share/zoneinfo/right/America/Los_Angeles. Otherwise, it java will not handle timezones correctly

Revision history for this message
Stephen Duncan Jr (stephen-duncan) wrote :

According to this post: http://forums.sun.com/thread.jspa?threadID=5402522 it's essentially arbitrary which name Java will parse out because it will use the first file it finds with the same contents.

For me on 9.10, the contents of /etc/localtime match /usr/share/zoneinfo/SystemV/EST5EDT; this does not match /usr/share/zoneinfo/right/SystemV/EST5EDT or /usr/share/zoneinfo/right/America/New_York (which are the same as each other).

Symlinking seems to be the most reliable option. I'm not clear on whether it should go to the "right" directory or not (unsure about leap-second handling, but I think either would be handled in Java/joda-time).

Revision history for this message
Stephen Duncan Jr (stephen-duncan) wrote :

Also these bugs in the Sun bug database indicate that Java will be changing it's algorithm, so perhaps this should be left as just a Java bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2180391
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628

Revision history for this message
Thomas Hotz (thotz-deactivatedaccount) wrote :

The two last mentioned bugs are fixed, so do you have still this problem? Thank you for telling us!

Changed in tzdata (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for tzdata (Ubuntu) because there has been no activity for 60 days.]

Changed in tzdata (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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