no (obvious) option to set hwclock to utc during 12.04 alternate install

Bug #946132 reported by Jane Atkinson on 2012-03-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone
clock-setup (Ubuntu)

Bug Description

When installing 12.04 from an alternate CD, the time setting dialogue checks that my timezone is correct, but it doesn't ask about whether the hardware clock should be set to local time or UTC.

The problem has been there since, possibly, the previous release; I initially upgraded to Precise from an Oneiric install, and after a lot of head-scratching, discovered that hwclock set to local time was causing problems such as unexpected errors on a shared partition, due (I presume) to timestamps being wrong.

I run Lucid on the same machine, and also Windows Vista with a fix to read the hwclock as UTC. After running Precise and then booting into Vista, I was getting the time showing as 13 hrs ahead of actual time. This corresponds to the 13 hrs that NZDT is ahead of UTC.

I did a fresh install of Precise from the Beta1 alternate CD and the same thing has happened.

If people who want to use UTC are supposed to answer "no" to the question about local timezone and then set UTC manually, it is not made clear during the installation.

Colin Watson (cjwatson) on 2012-03-13
affects: debian-installer (Ubuntu) → tzsetup (Ubuntu)
Jane Atkinson (irihapeti) wrote :

This is still present in beta 2 candidate. /etc/default/rcS shows "UTC=no" when the local time of Pacific/Auckland is confirmed during installation.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Colin Watson (cjwatson) wrote :

You should be able to say "no" and select UTC from the global list of timezones. This is a case where I can't really win, though; other people like there to be fewer questions by default ...

Colin Watson (cjwatson) wrote :

Oh, sorry, you said hardware clock, not timezone, so ignore that ... reassigning to clock-setup as this is actually handled in a different place from the timezone question.

I suspect that you have Windows installed, or (less likely) some other DOS-based system or Solaris. In such cases we set the hardware clock to localtime as doing otherwise tends to confuse Windows rather badly. You can override this with "clock-setup/utc=false" as a boot parameter, but we don't currently intend to add UI for it as it would be a rather odd "Break Windows? (yes/no)" kind of question.

affects: tzsetup (Ubuntu) → clock-setup (Ubuntu)
Changed in clock-setup (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Colin Watson (cjwatson) wrote :

And, re-reading your bug description, the real problem here is that we have no way to tell that you have a fix applied to Windows to make it read UTC from the hardware clock. Most people don't, of course.

Jane Atkinson (irihapeti) wrote :

I can understand now what is happening, and it sounds like it isn't really a bug but a design choice.

It would also explain why it's happening on the desktop computer and not on the EeePC which doesn't have Windows on it.

Perhaps the real issue for me was not knowing that it had changed. As you say, there is still the choice to select UTC from the list of timezones.

Maybe that could be clarified? It's an alternate installer, so possibly more likely to be used by the more "advanced" user.

But I quite understand that you have competing priorities to deal with. Sometimes I marvel that you manage to stay sane at all, with all the yelling that goes on. :)

Jane Atkinson (irihapeti) wrote :

There may still be a problem with this. The last install that I did, I chose "UTC" from the list of options. When I booted to the desktop, I set the timezone using date and time settings. Then I thought to check /etc/default/rcS -- and it showed "UTC=no"

I don't know if the file always had "UTC=no" in it, or whether it got written to when I set the timezone. I'll check more closely after the next install. Either way, I find it a bit disconcerting.

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

Other bug subscribers