livecd clock is (inevitably) wrong

Bug #105519 reported by Ian Jackson
40
This bug affects 4 people
Affects Status Importance Assigned to Milestone
casper (Guadalinex)
New
Undecided
Unassigned
casper (Ubuntu)
Won't Fix
Low
Unassigned

Bug Description

Binary package hint: gnome-panel

I booted the i386 livecd 20070411. The machine has a hardware clock set to UTC, a single hard disk containing only Linux installs, and although there is a network the firewall prevents it talking to any global ntp servers.

The clock in the top right corner of the desktop shows UTC, which is not the correct timezone for me at the moment. For many users the clock will be even more wrong.

Tags: iso-testing
Revision history for this message
Sebastien Bacher (seb128) wrote :

gnome-panel is using the system timezone

Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

Unless we can devise some clever way for the Live CD system to figure out where you are, this will often be wrong for people with UTC system clocks, indeed.

One option would be to not show the clock in the Live session ...

Changed in casper:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Ian Jackson (ijackson) wrote : Re: [Bug 105519] Re: livecd clock is (inevitably) wrong

Henrik Nilsen Omma writes ("[Bug 105519] Re: livecd clock is (inevitably) wrong"):
> One option would be to not show the clock in the Live session ...

That would be an improvement, I think.

Ian.

Revision history for this message
Peter Cordes (peter-cordes) wrote :

dhcp has a timezone option. I might not be widely used, but dhclient on the livecd should be configured to request timezone or location or whatever the option is. Then if the server does support it, you're all set.

 DHCP also supports a list of NTP servers, although that's not so necessary since Ubuntu seems to have a default for that anyway. It would be much better to use people's ISP's NTP servers, though.

 Many machines will have their BIOS clocks set to local time, so if you can get the difference between that and NTP time, that would be a good default for a timezone (although there are multiple timezones with the same time offset). Probably you'd have to record hwclock time, then do ntpdate, if ntpdate modifies the hwclock, too.

 On machines with BIOS clock = UTC, which is good if you never boot any silly OSes that don't support that, the livecd will just default to timezone = UTC, like before.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

There is also a problem if you mount a disk using the live CD, and then boot back into a normal installation. If you are in a UTC+something timezone, the last mounted timestamp will be in the future, and a file system check will be unnecessarily run.

Revision history for this message
Ernst Zlo (ernst-zlo) wrote :

Karmic:
The life CD seems to change the hardware clock to UTC, with the side effect, that Vista has UTC after the session.

And Vista doesn't even recognize (which is not the fault of Ubuntu, I know <eg>)

IMHO it would be better to leave the time unchanged, because on a live CD session the real exact time is not THAT important.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

The live CD should absolutely not touch the hardware clock, that would be a separate bug.

BTW, disregard my comment 5, it turned out to be the ext3/4 journal replay issue, now solved.

Revision history for this message
Mossroy (mossroy) wrote :

Agree with Tormod Volden : the live CD should not modify the hardware clock.
See https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/436535 which might be a duplicate

Revision history for this message
jage (jage) wrote :

Instead of setting the system clock (which appears to be 436535) can the LiveCD not just read the system clock? If it's wrong once the LiveCD is booted I imagine (I'm new) that Ubuntu can be used to set it manually. (Posted a similar comment in 436535 since while not the same the solution might be).

Changed in casper (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Stéphane Graber (stgraber) wrote :

casper isn't touching the clock at boot time.
ntpdate is triggered by ifupdown which sets the clock to the right time. The timezone is going to be UTC until a location is selected in ubiquity at which point the clock will change to reflect the timezone change.

I think the current behaviour is correct, though it indeed could be slightly improved by having NetworkManager parse the dhcp flag and expose that to the desktop environment somehow.

Changed in casper (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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