When I first turn on or reboot my computer the desktop clock displays UTC for about 2 minutes then automatically switches to local (UTC-5). The BIOS clock is on UTC. Running KDE 4.3.1 on openSUSE 11.2 64-bit. The problem is caused by something started before login because if I wait for a few minutes at the login screen the time will be correct when the desktop is displayed. I also dual boot Mint with GNOME and it always starts correctly.

When you installed SUSE, did you select the correct options at the locale screen?
To check, open YaST > System > Date & Time. Make sure "Hardware clock is set to UTC" is ticked.

Yes the UTC box is checked. I have verified that the BIOS clock has UTC after logging out of openSUSE and Mint. Everything does eventually end up correct but it takes about 2 minutes or so. It just seems to take some process an abnormal amount of time to finish up during boot. Not a real problem but just seems to be abnormal behavior.

The clock is one of the first things the system sets up when booting, so this doesn't make sense.

When the grey openSUSE screen comes up, press "Esc", and watch the lines go past. Not too long afterwards you will be taken to the graphical login prompt, so press Ctrl + Alt + F1 to get back to that screen if you haven't already seen "Setting up clock..." or something similar.

You can use Ctrl + Alt + F7 to get back to the graphical login prompt after you have done this.

Yes the clock is set very early on. Here is a section of the display from just a few lines into boot:

Mounting devpts at /dev/pts

ok
Starting udevd:
Loading drivers, .....more stuff here ........

Loading required kernel modules
Activating swap-devices in /etc/fstab...
Set System Time to the current Hardware Clock
Activating device mapper...

Checking file systems...
fsck from util-linux-ng 2.16
Checking all file systems.

Mounting local file systems...

### Now from closer to the end of the display ###

Starting smartd
Starting mail service (Postfix)
Starting network time protocol daemon (NTPD)
Starting CRON daemon

A few more lines before the prompt but it seems that Postfix fails??


At this point in time should the software clock have UTC or LOCAL (-5 offset applied) because the hardware clock does have UTC?

The Software clock is controlled by the Kernel and is inherently UTC, stored as the number of seconds from the UNIX epoch. Low level libraries and Kernel interfaces take care of making this human readable, and perform the Timezone conversion at the same time.

Try disabling NTP from startup to see what effect it has. YaST > System > Runlevel...

While making the last response I noticed the entry about NTP and tried killing it then. Today I put everything back as it was and disabled NTP in runlevel as you suggested. In both cases the clock displays UTC from startup and never switches to Local? If I start NTP manually later the Desktop clock will switch to Local time on the next minute update. This isn't that much of a problem and I really hate to take your time with it. I'm aware of it and after the computer has been on for about 2 minutes the time display is correct for Local time.

ABOUT 30 MINUTES LATER I FOUND THIS:
Here is a section from the NTP log. Maybe this is the problem? There is a router inline. Notice the time of the first and last entry!

22 Dec 16:31:59 ntpd[1709]: signal_no_reset: signal 17 had flags 4000000
22 Dec 16:32:01 ntpd[1709]: host name not found: chronos3.umt.edu
22 Dec 16:33:04 ntpd[1681]: Listening on interface #4 eth0, stuff 9#123 Enabled
22 Dec 16:33:04 ntpd[1681]: Listening on interface #5 eth0, 192. stuff #123 Enabled
22 Dec 16:33:04 ntpd[1681]: new interface(s) found: waking up resolver
22 Dec 11:33:58 ntpd[1681]: synchronized to 192.73.48.6, stratum 2
22 Dec 11:33:58 ntpd[1681]: kernel time sync status change 0001

ABOUT 3 HOURS LATER:
I have just installed openSUSE 11.2 32 bit on the partition that had the 64 bit with what I believe to be the exact same configuration and it works perfectly ever time it starts. Think I will stick to the 32 bit for the time being.

Extremely interesting. This was likely a bug in the setting of the "Hardware clock is UTC".