Comment 7 for bug 14241

(In reply to comment #5)
> The fact that hwclock performs translation for the time zone is concerning. It
> probably assumes that the BIOS clock is in UTC. It seems that setting the clock
> in GNOME *does* set the hardware clock.

It does not assume that the BIOS clock is in UTC; see the man page (--utc and
--localtime).

> I maintain that it's pointless to unconditionally synchronise the time to UTC on
> the live CD. This will only be correct for a small portion of your user base.

It is not pointless; it is important to have the correct time set in the system
clock.
This ensures that when you write files to a disk, they have the correct
timestamp, when you use a web browser, it can interpret Expires headers
correctly, and a variety of other things which assume that the system time is
correct.

UTC is used because to do otherwise would require asking the user which time
zone to use, which is undesirable for a live CD (where it usually doesn't matter).

> I also notice that the GNOME clock applet does not update when the time zone is
> changed (despite it having been done via a context menu on the clock!). I had
> to remove it and re-add it for it to display in local time.

bug #11629

> If it is necessary to synchronise the time, the user must be asked for the
> correct time zone (for both time display and hardware clock storage) or maybe
> the hardware clock offset could be guessed based on its previous and updated
values.

If there is a bug here, it is that the time setting tool makes it easy for the
user to inadvertently clobber their hardware clock with the wrong time. There
is no reason not to set the correct time in the system clock, and good reasons
to do so.