Espresso install doesn't ask if BIOS time is in UTC

Bug #37750 reported by Daniel Robitaille on 2006-04-02
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Declined for Intrepid by Colin Watson
Nominated for Jaunty by Ansus

Bug Description

During an espresso install, the installer only ask your time zone, but doesn't ask if the local time in the BIOS is in UTC or not.

So after my installation was completed, I had a system with UTC=yes in /etc/default/rcS.

In a dual-boot Windows-Ubuntu computer for the time to properly works in all the OSes an user must set UTC=no. It would be nice if the option was asked (or automatically set) during the installation so that unexperienced users (who are often the ones dual-booting with Windows in the first place) wouldn't have to edit that file in /etc/default manually afterward.

Erich Pawlik (erichpawlik) wrote :

See also bug #37830 and bug #34253 (for the Ubuntu standard installation).

Colin Watson (cjwatson) wrote :

This is entirely independent from bugs in the regular installer; the regular installer *has* user interface code for this, whereas at present Espresso does not.

Changed in espresso:
status: Unconfirmed → Confirmed

Confirm. This annoying bug still present in flight-7 "Desktop" CD installer (at least on AMD64 arch).

Colin Watson (cjwatson) wrote :

Ubiquity (as of 0.99.82) now runs clock-setup to attempt to automatically work out whether to set the hardware clock to UTC or not (based on the usual metric of whether Windows etc. is installed). With any luck this will deal with most users, and I've arranged for it to be possible to boot with 'clock-setup/utc=false' (or true) in case it gets it wrong.

Unfortunately I think I'm now out of time to add a proper UI for this for Dapper as opposed to crude boot arguments. I'll deal with that in Edgy.

Kai F. Lahmann (kfl) wrote :

imho the default should be just changed to set UTC=no and never ask the user. There is no practical use for this function, except producing problems with Windows.

Colin Watson (cjwatson) wrote :

Kai, that is very much not true. UTC=no produces horrible problems all over the place with daylight savings time; see for instance the archives of the RISKS mailing list. I have absolutely no intention of making it the default where I don't have to.

I have the same problem.

KDE has the right time, but when I choose my timezone the installer produces a timezone that is two hours off.

Just curious: Why is it that anybody want their hardware clock set to utc? I don't understand it.

Colin Watson (cjwatson) wrote :

Daylight savings handling does not belong in hardware. Why would you want your hardware to have to keep track of a setting which can change depending on the whim of your local legislature at as little as a few months' notice?

(This is a slightly rhetorical question; Windows has a poor design so some people have to do it this way. But it's really, really not optimal for anyone who doesn't have to do it.)

Colin Watson (cjwatson) wrote :

For more detail about why the use of local time in the hardware clock is a dangerously wrong practice by Microsoft operating systems, see:

Richard Boudreau (rbo83) wrote :

On GUTSY, same annoyance. Why does the system not use the same Administration Time/Date menu as Fedora and Freespire, where there is a checkbox to set if the local computer time is/is not in UTC, which would automatically change /etc/default/rcS. I use multi-boot Ubuntu, Fedora, Knoppix, Freespire and WINXP. AT least all the Gnome/KDE date time functions should all act the same. The code is already there anyway. It does not matter who believes is the best, just assume it is whatever, but allow the user to change it so it does not conflict with other boot systems. Remember we are all trying to get Windows users to move to LINUX. Let's just make it easy.

Ansus (neptunia) wrote :

Still in Hardy. Very annoying.

Ansus (neptunia) wrote :

I know many people and those who ask in Russian forums how to fix this bug. Some people set the time in Windows and Fedora to a timezone 3 hours different from actual to have time in those OSes to be the same as in Ubuntu. Most people even do not know that there is a workaround (editing the config file).

If I had not encounterd an old description of this bug (dating from Ubuntu 4.10), I would probably abandon Ubuntu I think.

Colin Watson (cjwatson) wrote :

As previously explained, I don't think we should change the default, but I think we probably ought to add a checkbox to the timezone screen for Jaunty.

Jonathan Marsden (jmarsden) wrote :

Is the bug that the current "Windows detection" code is flawed or absent, so Ubuntu installs with UTC=yes even when there is a Windows partition visible?

Or, is the bug perhaps that some people install Ubuntu first (so getting UTC=yes, correctly), and then later install Windows, and subsequently the two OSes conflict over their interpretation of the hardware clock?

It seems unfortunate to add an extra question/checkbox to the installer dialog if this can be reliably determined automatically. Perhaps adding a way to set this in System -> Administration -> Time and Date (and the equivalent KDE utility) would be preferable -- keeping the installer simple, but giving people who add Windows to their Ubuntu machine an easy graphical way to set their hardware clock to local time?

Benjamin Drung (bdrung) wrote :

It is the second case: You have installed Ubuntu before Windows or while installing Ubuntu the hard drive with the Windows partition is not plugged in.

Your suggestion to add an option to System -> Administration -> Time and Date sound good and would solve this problem too.

Ansus (neptunia) wrote :

In fact there was such checkbox in time properties in Ubuntu 7.10 but it did not work and you had to change the config file manually.

summary: - doesn't ask if BIOS time is in UTC
+ Espresso install doesn't ask if BIOS time is in UTC
Phillip Susi (psusi) on 2014-01-07
Changed in ubiquity (Ubuntu):
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers