Comment 5 for bug 14241

Trying Ubuntu with GNOME again:

Before correcting the clock:
ubuntu@pepper:~$ date
Sun Mar 20 00:47:15 UTC 2005
ubuntu@pepper:~$ hwclock -r
Sun 20 Mar 2005 11:47:56 UTC -0.894950 seconds

After correcting the clock:
ubuntu@pepper:~$ date
Sun Mar 20 11:49:39 EST 2005
ubuntu@pepper:~$ hwclock -r
Sun 20 Mar 2005 11:48:43 EST -0.665632 seconds

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.

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.

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.

The only usual purpose I can think of for accurately synchronising time is to
ensure that all systems (especially on the LAN) maintain the same time so that
file's timestamps are consistent and so on. In this case, it would be far
better to synchronise against the local network's NTP server (advertised using
DHCP) in preference to a global time server. It's also not very useful, since
NFS doesn't work well, and I doubt other distributed file systems (AFS, DFS,
Coda, etc.) are supported by default on the live CD.

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.