[time-admin] doesn't switch off synchronisation with time servers

Bug #37383 reported by Erich Pawlik
12
Affects Status Importance Assigned to Milestone
gnome-system-tools (Ubuntu)
Invalid
Medium
Ubuntu Desktop Bugs

Bug Description

(I have report the same issue as bug #37380. I have filed two bug reports since I feel that two packages are involved).

During installation I did set the timezone to Europe/Berlin. After leaving Ubuntu, the system clock is set back by 2 hours (which is exactly UTC). After that, Ubuntu doesn't change the clock any more. This behaviour is a major annoyance in dual configurations since Windows XP will show the wrong time.

Via Gnome time-admin, I did switch off periodic synchronisation with time servers. This didn't solve the problem. After setting the bios clock to local time, nethertheless Ubuntu did change the bios clock back to UTC again. Since Ubuntu sets back the time only once, it will be that Ubuntu contacts a time server despite the setting in time-admin.

Tags: time-admin
description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. What do you expect from that application? You can change the /etc/default/rcS UTC= key to define if your system clock has the UTC time or the local one. Does that fix your issue? The question is not asked during the information to make it simple, so it assumes that the PC clock is set to UTC which is the default

Changed in gnome-system-tools:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Erich Pawlik (erichpawlik) wrote :

Your question is related to my issue about debian-installer (bug #37380). I will answer your question in a post at that bug.

However, there seems to be another issue related to the Gnome time-admin panel or the Gnome clock panel:

Have a look at the following scenario:

1. /etc/default/rcS UTC=yes (set by the installer)
2. In the "Time and Date Settings" panel, "Periodically synchronize clock with Internet servers" is checked off.
3. Ubuntu interprets the system clock (which is local time) as UTC
4. Ubuntu somehow finds out that the system clock deviates from UTC
5. After booting again, the clock remains unchanged until I boot into Windows again (and set the clock) or change the clock in the bios settings.

My basic issue is that Ubuntu somehow knows the correct UTC and doesn't accept the time returned by the system clock. I guess that this is only possible by contacting a time server (but I am not sure). I would expect that this doesn't happen if I switch off synchronization with Internet servers.

You might argue that this option only switches off "periodic" synchronization and that a sychronization at boot time (or whenever else) is ok. However, there should be a way to tell Ubuntu to stay away from the system clock. In a dual boot configuration, it is otherwise impossible to have a consistent clock setting.

One observation that mystifies me: When I check the option "Periodically synchronize clock with Internet servers" on and off, ntp.conf remains unchanged; however ntpd, will be started and stopped as I would expect (and when stopped, ntpd will not show up after reboot again). Taking ntpd out of the equation obviously doesn't solve the problem.

There could be something with the Gnome (or Ubuntu) clock applet. I have tried the following settings:
- /etc/default/rcS UTC=yes
- Periodically synchronize clock with Internet servers = off
- clock applet: Use UTC=off
If my system clock is "17:11" and my timezone is "Europe/Berlin" (currently UTC+2h), the applet should show "19:11". However, it shows "17:11". And after leaving Ubuntu, the bios clock is set to 15:11.

Regards

Erich

Revision history for this message
Sebastien Bacher (seb128) wrote :

For a box using windows and linux you want to set UTC=no and that should work fine

Revision history for this message
Erich Pawlik (erichpawlik) wrote :

Setting UTC=no doesn't solve this particular bug report. Using UTC=no has a big disadvantage right now (see Bug #33968), but I can work around that bug for the timne being as well (restarting networking does the trick).

This bug report is about a inconsistency in handling time services with UTC=yes. This inconsistency might be related to bug #33968, but up to now, I don't have any evidence for this.

Regards

Erich Pawlik

.

Changed in gnome-system-tools:
status: Needs Info → Unconfirmed
Revision history for this message
steve196 (steve196) wrote :

Similar thing here with hardy alpha 4 installed through wubi.
During installation it sets the time to something (not utc but apparently some American timezone, perhaps guessed from language settings) without asking me where i am.
After i have set the timezone to central Europe, it is always one hour off, but not one hour late (which would be Greenwich time) but one hour early, as if it was already daylight saving time, while it is the middle of February. If i correct the time manually, ubuntu sets it back at next reboot, whether i set it to connect to timeservers or not.

Revision history for this message
Basilio Kublik (sourcercito) wrote :

The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the actively developed release. You can find out more about the development release at [WWW] http://www.ubuntu.com/testing/

Changed in gnome-system-tools:
status: New → Incomplete
Revision history for this message
Pedro Villavicencio (pedro) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

Changed in gnome-system-tools:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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