LinuxQuestions.org - [SOLVED] Weird time changes, correct time and date but wrong hour

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Weird time changes, correct time and date but wrong hour (https://www.linuxquestions.org/questions/slackware-14/weird-time-changes-correct-time-and-date-but-wrong-hour-4175513031/)

Weird time changes, correct time and date but wrong hour

This has happened twice that I have noticed it. The first time it happened I assumed the CMOS battery ran out, so I changed it, which caused some issues that I had to fix. The CMOS battery is brand new ATM (since a few weeks ago), and it has happened again.

The hour changes maybe after booting up, but I don't always check, but the date and minutes and seconds are correct.

For example, the real time now is 6:05:44, but my computer time is 'Fri Aug 1 23:05:44 CDT 2014'.

I do have ntpd setup as follows:

Code:

server        127.127.1.0        # local clock

fudge        127.127.1.0 stratum 10



#

# NTP server (list one or more) to synchronize with:

server 0.north-america.pool.ntp.org iburst

server 1.north-america.pool.ntp.org iburst

server 2.north-america.pool.ntp.org iburst

server 3.north-america.pool.ntp.org iburst



driftfile /etc/ntp/drift



# Don't serve time or stats to anyone else by default (more secure)

restrict default noquery nomodify



#

# Trust ourselves.  :-)

restrict 127.0.0.1

If I run 'ntpdate 0.north-america.pool.ntp.org' the time is set correctly to 6:05. With:

Code:

bash-4.2# ntpdate 0.north-america.pool.ntp.org

 1 Aug 18:11:11 ntpdate[20504]: step time server 204.235.61.9 offset -18000.913724 sec

Is there something I'm missing, this has never happened before. Is it hardware ? I have no clue what it could be.

CDT is the correct time zone, BTW. Oh, and there have been no power outages AFAIK.

The hour offset appears to be the difference between local time and UTC (+5). This is typically caused by the hardware clock being set to local time and the OS thinks it is UTC or vice versa. If you dual boot, windows expects the hardware clock to be UTC. You can use the hwclock command to change the clock reference.

http://www.pc-freak.net/blog/how-to-...time-troubles/

Linux systems are generally set to UTC (Greenwich) time, and the time zone settings are used to adjust the display time to local time. Based on the difference between 18:00 (6 p. m.) and 23:00, I think that the former is local time and the latter is UTC. (That would be UTC -5; EDT is UDT -4.)

What are the outputs of

Code:

hwclock

date

date -u

This link may help. Note that it is part of a larger document.

Quote:

Originally Posted by frankbell (Post 5213471)

Code:

hwclock

date

date -u

This link may help. Note that it is part of a larger document.

Here is the output:

Code:

bash-4.2# hwclock

Sat 02 Aug 2014 05:38:51 AM CDT  -0.469908 seconds

bash-4.2# date

Fri Aug  1 19:38:49 CDT 2014

bash-4.2# date -u

Sat Aug  2 00:38:50 UTC 2014

I guess I better check the UEFI settings.

I'm only running slackware64 14.1, no dual boot.

Are you dual booting with windows

MS only uses the clock( on the MOBO) set to YOUR LOCAL time zone

Linux can use MS's OR use it set to UTC

setting the clock to UTC is preferred

the clock is set to UTC then the desktop converts it to your LOCAL time

instead of MS's way of converting your local to UTC for the web

if you dual boot you HAVE!!!! to use Microsoft's way of setting the time !!!!

if you do not
windows will be off by the difference of the time zone

I just checked the time in the UEFI firmware, it is correct at 7:52, here is the output of those commands now:

Code:

bash-4.2# hwclock

Fri 01 Aug 2014 07:50:30 PM CDT  -0.235298 seconds

bash-4.2# date

Fri Aug  1 19:50:35 CDT 2014

bash-4.2# date -u

Sat Aug  2 00:50:37 UTC 2014

I'm still not entirely sure of the cause. Maybe it is the UEFI messing up ?

Using UTC as the base time seems so annoying to me. But thats just me.

If "hwclock" is supposed to be internal clock, then its wrong... Go in to BIOS and set it to CDT.

The reason you are getting two different times is because at all times, it picks up the BIOS clock FIRST, then attempts to connect to a time server for adjustments. If it picks up the time server, it "fixes" your time, but only in the OS, not in BIOS. If there's a hickup or something during that attempt and it fails, it leaves it with the BIOS time. There are a few systems that allow the BIOS time to get changed by time servers from the OS, but it requires support AND correct settings elsewhere.

I personally make it a point that my BIOS time matches my local time and ignore time servers exactly because they don't always pick up. Then let OS deal with DST vs STD time.

Edit: ooh, i should've quoted... This was based on the earlier message where hwclock gave UTC.

If the BIOS is flip/flopping between, maybe you do have the setting to adjust the BIOS from the OS, and one of the time servers itself is giving wrong time... Maybe.

If one of the time servers is bad, someone else would have noticed, because these are official servers:
http://www.pool.ntp.org/zone/north-america

The hardware clock is local time.
Look at the contents of file /etc/adjtime. Is it local or UTC?

It says local:

Code:

0.000000 1406940576 0.000000

1406940576

LOCAL

shut the puppy down, go into BIOS and see what it says there.

I think it is obviously the difference between your localtime and UTC.

I always use UTC for the hardware clock, so will assume that in what follows (but will work the same if you select NO - Local in timeconfig).

The idea here is to get all clocks and configs aligned to the same reference point.

First:

Code:

cat /etc/hardwareclock

It should say UTC

If not, as root:

Code:

timeconfig

Select "Yes - Hardwareclock is set to UTC"

Select your local timezone

Now we know your config is OK, but are unsure if your clock(s) are right, so let's just set them...

Code:

First set the system clock:



date -s hhmm (assumes date is correct, hhmm is local time hour and minutes)

date (make sure it looks right...)



Then set hardware clock from system clock:



hwclock --systohc

Now your hardware clock will be set from your system clock according to UTC and local timezone offset...

That should do it!

If your CMOS time stays at the correct localtime, then it's probably an incorrect 'UTC' value in /etc/hardwareclock. Slackware's rc.S script use that in preference to the value stored in /etc/adjtime.

There are some issues with using ntp and a hwclock set to localtime that are discussed in http://www.linuxquestions.org/questi...me-4175477525/. If you find that the UEFI/CMOS time is also jumping by those 4/5 hours then I have some ideas on that, but we'll cross that bridge when we get to it.

Thank you GazL, I think that thread is exactly the issue here, and it looks like the best solution is to set the system time to UTC. Alright, I'll do that.

I didn't realize the clock was being set to UTC otherwise I would have found the other thread.

Here's a nice, confusing little treatise about time... well, about keeping time.

You have two clocks: the hardware clock and the software clock. The hardware clock is a chip (or part of a chip) on your motherboard kept running by the CMOS battery when the system is powered off (some motherboards will keep it running if the system is plugged in and turned off; I have a couple of those). The system clock is software managed by the kernel with interrupts (pretty much).

When Slackware boots, the hardware clock is read by some code in /etc/rc.d/rc.S:

Code:

# Set the system time from the hardware clock using hwclock --hctosys.

if [ -x /sbin/hwclock ]; then

  # Check for a broken motherboard RTC clock (where ioports for rtc are

  # unknown) to prevent hwclock causing a hang:

  if ! grep -q -w rtc /proc/ioports ; then

    CLOCK_OPT="--directisa"

  fi

  if grep -wq "^UTC" /etc/hardwareclock ; then

    echo -n "Setting system time from the hardware clock (UTC): "

    /sbin/hwclock $CLOCK_OPT --utc --hctosys

  else

    echo -n "Setting system time from the hardware clock (localtime): "

    /sbin/hwclock $CLOCK_OPT --localtime --hctosys

  fi

  date

fi

Note that the above looks at /etc/hardwareclock to see if the hardware clock is UTC or local time and acts accordingly. A hardware clock running UTC looks like this:

Code:

cat /etc/hardwareclock

# /etc/hardwareclock

#

# Tells how the hardware clock time is stored.

# You should run timeconfig to edit this file.



UTC

You're in the central time zone in North America? OK, that's six hours difference from UTC during standard time and five hours from UTC in daylight time; that "difference" is X hours less than UTC.

For example, I'm in the eastern time zone, daylight time is in effect and my local time is four hours less than UTC (it's five hours when standard time is in effect):

Code:

date

Sat Aug  2 12:45:29 EDT 2014

date -u

Sat Aug  2 16:45:36 UTC 2014

Now, NTP, when synchronized, keeps your system clock on time (it doesn't mess with the hardware clock).

As during start up -- boot -- when the system is shut down /etc/rc.0 has code to save the system time to the hardware clock:

Code:

# Save the system time to the hardware clock using hwclock --systohc.

if [ -x /sbin/hwclock ]; then

  # Check for a broken motherboard RTC clock (where ioports for rtc are

  # unknown) to prevent hwclock causing a hang:

  if ! grep -q -w rtc /proc/ioports ; then

    CLOCK_OPT="--directisa"

  fi

  if grep -q "^UTC" /etc/hardwareclock 2> /dev/null ; then

    echo "Saving system time to the hardware clock (UTC)."

    /sbin/hwclock $CLOCK_OPT --utc --systohc

  else

    echo "Saving system time to the hardware clock (localtime)."

    /sbin/hwclock  $CLOCK_OPT --localtime --systohc

  fi

fi

Note that both /etc/rc.0 and /etc/rc.S check to see how the hardware clock is set, either UTC or local time, to write the "correct" value to the hardware clock.

If you're just rebooting, all that writing to the hardware clock is done by /etc/rc.d/rc.6 but the reading from the hardware clock and setting of the system clock is the same (handled by /etc/rc.d/rc.S).

Should you keep your hardware clock on UTC? Well, yeah, you probably ought to (there's some movement afoot in kernel development to default all hardware clocks to UTC and be done with it -- hasn't happened yet but it just might so why fool around).

NTP will keep your system clock on time (they're notorious for drifting all over the place). You configuration looks pretty much OK, but I'd recommend that you only use three servers and delete the iburst from them (they're not really necessary).

You need to be root do the following.

Others have recommended that you run timeconfig, setting your hardware clock to UTC and picking the correct time zone, which would be US central time. Yup, do that (be sure and stop NTPD first).

The ntpdate utility is depreciated and you should use ntpd instead to set the system time correctly:

Code:

ntpd -q

That will use the servers you have defined in /etc/ntp.conf to set the system time (it will pick the best one) and exit.

Then you set the hardware clock:

Code:

hwclock --systohc

(the above is from @astrogeek's post).

That should do it.

You can start NTPD, wait about 5-10 minutes and run

Code:

/usr/sbin/ntpq -pn

    remote          refid      st t when poll reach  delay  offset  jitter

==============================================================================

 127.127.1.0    .LOCL.          10 l  5h  64    0    0.000    0.000  0.000

+69.50.219.51    173.44.32.10    3 u  197 1024  377  648.346  71.386  81.450

*199.102.46.75  .GPS.            1 u  278 1024  377  662.432  76.805  74.333

+209.118.204.201 10.55.5.56      2 u  154 1024  377  728.621  57.467 125.183

(you use -pn so you're not going through DNS to get the addresses).

When you see a display like this, with the + and *, you're synchronized and you'll stay that way (the one with the asterisk is the external server you're synchronized to).

When you reboot or shut down, the correct time will be written to the hardware clock (then read from the hardware clock to set the software clock on the next boot). If that time drifts, you most likely have a bad battery (hey, it happens that you buy a new battery that's no good you know). You can check the next time you start the box from powered off by entering the BIOS (or UEFI) and see what time it is -- it should not have drifted more than 1,000 seconds even if powered off for a week or two.

Over time, NTPD will "walk" your system clock into synchronization by using the drift value found in /etc/ntp/drift and keep it there; it takes a while for that to happen (like days, sometime a week or two) but it will get there if you leave the system running 24/7.

Anyway, hop this helps some.