As far as I know I don't have any ntp time server installed.

Something is checking somewhere for the time. My system is set up for eastern standard time. Whatever is checking the time on the web is checking a server that is also on Eastern standard time and subtracting five hours.

To make matters even worse the other computer on my little home lan is checking the first computer and subtracting another five hours.

So my main internet connected computer is five hours early and the other computer is ten hours early.

I sort of enjoy the weird humor but this screws some software up.

Thanks for any help.

That all sounds very strange. You didn't say how you have come to the conclusions you have. I will note that the NTP protocol uses UTC (essentially GMT), so if the machine running the server is set up properly, it shouldn't matter what time zone the server is in. (If your systems are using NTP.) Also, internally Linux systems run on UTC and just translate to a time zone when interacting with a user. Still, I can't help but observe that 5 hours is the offset between EST and UTC.

There are a couple of things I can think of that might get you some more info.

• You can use a packet sniffer like wireshark or tcpdump to look at network traffic so you can see exactly what is going on
• If you run netstat as root (or using sudo), the -p option will list the program and PID using each socket. If NTP is being used on the default port (udp/123), you probably want to use the -naup options.

I was guessing that the internet was involved.
Further checking lead to more information:

I have a dual-boot machine with windows 2000 on it. If I boot to windows and synch with an internet time server my time is correct. If I reboot to windows the time remains correct.
Now if I reboot to linux my time is again incorrect.
The following screenshots from windows show that something in the linux bootup is wrongly correcting UTC by five hours. I have no clue as to what is causing this or how to correct it.

At one point I had ntp daemon installed on this machine but I used Synaptic to completely remove it.

If I type sudo ntpdate pool.ntp.org the time is also correctly set. At the next boot it will be wrong again.

Actually I don't see a way to post images. What the picture shows is that UTC is incorrectly offset by 5 hours.

I'm not familiar with a way to check UTC in linux.

Your time at boot is wrong because your BIOS clock is not UTC but local time. UTC is Linux default, you have to tell Ubuntu your BIOS clock is set to local time. Windows does not support UTC time in BIOS.

TMK, MS Windows requires the hardware clock to be local time. (Concurring with Emerson.) So you need to tell Linux to do the same. Ubuntu (at least in edgy) controls this in /etc/default/rcS. You want to change

UTC=yes

to

UTC=no

I suggest you make this change, then boot to MS and get the time synced up and then boot back to Linux and verify that everything is OK.

-------

Based on your last post, perhaps a quick review of the way time works in Linux is in order:

The hardware clock (aka BIOS clock, aka cmos clock) is normally ignored except at boot time and potentially at shutdown. While Linux is running, the kernel maintains the system time, which is in UTC. (Internally, it is the number of seconds since the beginning of 1970 UTC.) At boot time one of the init scripts (/etc/init.d/hwclock.sh in Ubuntu) reads the hardware clock and along with the setting described above and the locale info (if hwclock is not on UTC) sets the system clock. Unless you are running something like ntpd the kernel then pays no more attention to the hardware clock. (If you are running ntpd there is a mechanism to keep the hardware clock synced to system time.) By default, when Ubuntu shuts down, it will write the system time back to the hardware clock after again consulting the UTC and locale settings. (I don't know whether all distros now do this. It did not used to be standard.)

Normally programs that interact with the user will translate between system time (UTC) and local time. In particular GUI clocks (depending on their settings), the date command and the ls command will do this.

The default output of the date command is in local time (if the locale is properly set). If you use the -u option then date will display the time in UTC. There are actually a number of different things the date command can do depending on options. Check its man page for details.

In passing, I'll note that when you ran ntpdate it only set the system clock (not the hardware clock). However, unless you've changed the default behavior or unless things have changed since edgy, I would have expected the new time to get written to the hardware clock on shutdown.

I hope this brief explanation has been helpful.

Thanks for your response.

I had already read /usr/share/doc/util-linux/README.Debian.hwclock and checked /etc/edfault/rcS before I got the post.

rcS has UTC=no already set.

I set the clock correctly in BIOS this morning before boot. At some point dmesg shows the correct BIOS time. When the system arrives at the desktop it is again wrong by 5 hours.

Also if I'm understanding the system correctly the correct time found by ntpdate should set the BIOS clock at shutdown.

I'll shut down the system now and see if that is correct.

After running ntpdate and obtaining a correct time I rebooted and checked the BIOS time. (hardware clock)

It reflected the time correctly. So shut down is setting the hardware clock.

I double checked my system time zone and it is also correct.

I am now totally baffled.

Are you saying the problem is fixed & you are concerned because you don't know why?

Is the system time now correct or incorrect.? W/o options, does the date command show the EST time zone? How are you "checking BIOS time?" (E.g., what command do you run?)

Sorry for the delay. A major storm blew out my internet connection.

My time is still working incorrectly.

Before ntpdate:
SOL:~$ date
Wed Mar 5 13:20:07 EST 2008
SOL:~$ date -u
Wed Mar 5 18:20:13 UTC 2008

SOL:~$ sudo ntpdate ntp.ubuntu.com
6 Mar 09:34:54 ntpdate[5650]: step time server 91.189.94.4 offset 71998.594685 sec

After ntpdate:

SOL:~$ date
Thu Mar 6 09:35:54 EST 2008
SOL:~$ date -u
Thu Mar 6 14:36:00 UTC 2008

If I now the now reboot and enter the bios management screen the bios clock will show Thu Mar 6 09:35:54 2008.

Afte I proceed to boot into the linux operating system the time will be wrong again.

Just adding more information after a reboot.

Poenix cmos setup utility
Standard CMOS Features

Date Thu Mar 6 2008
Time 10:16:55

So the system is setting the hardware clock correctly at shutdown.

After exiting CMOS setup and linux boot.

SOL:~$ date
Thu Mar 6 05:18:48 EST 2008
SOL:~$ date -u
Thu Mar 6 10:18:57 UTC 2008
SOL:~$ sudo gedit /etc/default/rcS (output follows)

# /etc/default/rcS
# Default settings for the scripts in /etc/rcS.d/
# For information about these variables see the rcS(5) manual page.
# This file belongs to the "initscripts" package.
TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=no
VERBOSE=no
FSCKFIX=no

Something is happening in the boot process that is changing the time it reads from the hardware clock to the incorrect time.
I know of no way to single step through boot and I don't think I'd want to. Ubuntu has no boot log other than dmesg.
That's why I'm baffled. I don't know where to look next for a resolution to this problem.

I'm pretty sure the reason for this problem is that I don't use GDM but just log in and start X from the command line. Server installs would be the same and they can't have the wrong time.

Maybe most server installs use some other distro. Considering the way I have the system set up maybe I should consider that myself.

Here are the entire contents of /var/log/boot:
(Nothing has been logged yet.)

Thanks for all the help so far.

Are you saying the clock is correct before you start X?

The time is also incorrect before starting X.

However I know from my experience from a full Ubuntu install that GDM actually loads a bunch of stuff before it starts the X session.

I'm guessing that one of the things GDM may be doing is setting the time correctly.

My reason for this suspicion is that usually a quick web search on a given problem will find many pages of similar problems. Other than the UTC=no thing I seem to be totally alone here.

The standard install worked on this machine and the custom one does not. I'm guessing why.

The custom install was a standard full ubuntu install from the alternate cd. I then removed nautilus, metacity and GDM. After that I installed openbox. Since startx worked incorrectly I just type xinit at the command line after logging in.

Did you try tzselect utility to set your timezone again? What's in /etc/timezone?

I had completely forgotten that I had Ubuntu installed on another drive. Usually when I install a new distribution I park it on an older drive in my box. That way I have a working system while I work out the bugs in the new system. Then I install it on the newer drive.

After booting to the other drive, running ntpdate and rebooting to the other drive the time was correct.

This eliminates everything except the ntp package:

Package: ntp (1:4.2.4p0+dfsg-1ubuntu2)
Network Time Protocol daemon and utility programs

NTP, the Network Time Protocol, is used to keep computer clocks accurate by synchronizing them over the Internet or a local network, or by following an accurate hardware receiver that interprets GPS, DCF-77, NIST or similar time signals.

This package contains the NTP daemon and utility programs. An NTP daemon needs to be running on each host that is to have its clock accuracy controlled by NTP. The same NTP daemon is also used to provide NTP service to other hosts.

I had synaptic completely remove this package but I suspect it still is operating.

The problem I was originally trying to solve is setting the time on the laptop from the desktop over my little lan.

Ntpdate will not work behind a proxy. So I thought I would sync it with the desktop.

I know the ntp package was messing up the time on both computers which is why I removed it.

I've run into this before on linux especially with network stuff. The package is removed but the scripts etc are not.

This leaves the system unstable.

Short of a complete reinstall I don't know how to fix it.