Clock Ignores Return To Standard Time
 

I am using Slackware 13.37, 32-bit, KDE desktop environment. Not much of an expert with Linux but willing to learn...

North America went back to Standard Time this past Sunday at 2:00 AM. The clock of my 13.37 install ignores this fact.

When I installed Slackware, I selected the option specifying that my hardware clock is not set to UTC/GMT. My desktop is too old for having such an option in the BIOS anyhow.

I also made sure to select the correct time zone where I live within the USA and to pick a time server for time synchronization.

Therefore, when I turned my desktop on yesterday, I was expecting the clock to sync with the time server and show the correct Standard Time for my time zone. Instead, it was still one hour ahead. Today nothing has changed!

Doesn't Slackware sync time with the server upon booting up? Or do I have to manually adjust the time myself when Daylight Savings Time starts/ends?

Yes, it does (and, yes, 13.37 does), but... have you installed all the patches? There was a problem with at least one package that affected the daylight switch. It may or may not switch at boot (ought to with current patch levels); see date below.

If you have not installed all the patches, you might
And, what does date show you? Should look a lot like this (if you're in the Eastern time zone):
Too, are you syncing with NTP?

Hope this helps some.

Here's a thread from last year on the same subject...

http://www.linuxquestions.org/questi...3-37-a-912141/

My takeaway was that you either need to have the hardware clock set to UTC, run NTPD, or leave your system on overnight twice a year. You probably have an error message in /var/log/messages from ntp that says something like too big an offset to adjust the time.

You could just keep your computer off until March 10, 2013 when we move forward again. ;-)

Syncing to a network time source (NTP server) has nothing to do with time zones or Daylight Saving Time. The NTP server keeps your clock synchronized but it works in UTC, so it won't help with your timezone or DST adjustment. That is up to your local system.

There is no such thing as a BIOS "too old" for UTC. If your PC runs only Linux, you can just set your BIOS clock to the current UTC date and time, and tell Slackware that your hardware clock is set to UTC. Your timezone and DST will adjust automatically.

If, however, your PC also boots Windows, you probably need to set the BIOS clock to local time for Windows. (And if I recall Windows will change your hardware clock the first time it boots after DST starts and ends.)

And, of course, take a look at http://wondermark.com/883/ for another possible solution...

Turns out that I have an older Dell Dimension 8400 that's just been sitting in a closet turned off for, oh, two weeks or so; it's running Slackware 13.37 with all patches applied. The hardware clock is set to UTC. I just turned it on and, yup, it's the right time:
So, yes, it did adjust itself at boot and, because it runs NTP, it sync up with external time sources:
There are two things I can think of that may have led to your problem. One, if you dual-boot any version of Windows (as suggested above by @ljb643), Windows rolled the clock one hour on you -- Windows sets the hardware clock. The other is that the patches haven't been applied and that caused a problem.

If you are dual-booting Windows you can stop this behavior by booting it, click Control Panel, click Date and Time, click Time Zone and remove the check mark from Automatically Adjust for Daylight Time (this assumes XP, the same thing is doable in Vista or Win 7 in slightly different ways).

On the other hand, if you're not dual-booting, you can simply set the hardware clock to UTC using, say, http://www.time.gov/timezone.cgi?UTC/s/0, select UTC at the lower right of the green map display then
The time shown is always local time even if you keep your hardware clock in UTC.

Now, to set the hardware clock to UTC, just look at the UTC displayed time at NIST and round it up to the next 30 second or minute (to give you enough time to type the thing, eh?), UTC right now is 14:32:21 so I'll round to the next mintute
But don't hit the enter key until NIST rolls around to the minute. That will get your hardware clock set to UTC which never switches to what I like to think of as "stupid time."

Then you need to worry about system time.

Bear in mind that there is only one actual clock (the hardware clock) and system time is software (it's a clock in the kernel driven by a timer interrupt). At boot, the software looks at the hardware clock and gets set to whatever your local time zone is (in the eastern time zone in the US, that's five hours earlier than UTC when not on daylight time).

You can run timeconfig. Indicate that your hardware clock is set to UTC and select your time zone (eastern, central, etc.), reboot the thing and it should display the correct local time for you.

You've indicated that you shut the computer off at night so setting your hardware clock to UTC is a really good idea so that when daylight time rolls around twice a year you won't have the one hour glitch; the time zone stuff will work properly setting your system time for daylight or not daylight when you boot it in the morning.

It's also a good idea to set up NTP so that when you shut the system down the system time (which is what NTP keeps correct) is saved to the hardware clock -- that's part of the shutdown sequence, that saving system time to the hardware clock. They both drift and NTP is the best way to keep them on time. If you don't have an "always on" internet connection you want to manually start NTPD running after you've connected to the internet, say
That display is for three pool servers where /etc/ntp.conf has these entries in the server section near the top of the file:
Those work and you don't need to fiddle with anything else in /etc/ntp.conf to get it going, just edit the default file included with Slackware (but fiddle with it when NTPD is not running, eh?). You do want the local clock lines there so that when the internet is not available NTPD can sync to itself until the internet does become available.

Give this stuff a try and see.

Hope this helps some.

Thank you, Tronayne, for the effort made in addressing my problem!

I gather from your explanation that there is no way for Microsoft Windows and Slackware (and all other distros?) to coexist peacefully? I mean, if I set the hardware clock to UTC then the Windows clock will be wrong. On the other hand, if I do not set the hardware clock to UTC then it is Slackware that has clock problems...

Ideally, I would like to leave the hardware clock set to local time so that it does not interfere with the Windows clock and find a solution within Slackware. The only way that I have found so far in order to solve this Daylight Savings Time/Standard Time thing is to first boot up Microsoft Windows, let Windows adjust the hardware clock, shut down Windows, boot up Slackware and voilà the clock is now set to the correct time for both OSs. But, Jeez, we are in the 21st century! There ought to be a more elegant way of solving this issue. I do not expect Microsoft to come up with a solution but I thought for sure that in Linux there would be one.

What exactly am I doing when, within KDE, I have the clock set to the correct time zone and have a time server selected? Wouldn't KDE, upon being launched after booting up, poll the time server and adjust the Slackware clock according to the time zone selected, regardless of whether or not my hardware clock is set to UTC?

Sorry, I am just a newbie trying to understand...

Actually, Slackware doesn't have a problem. You can set your hardware clock to UTC or to local time and daylight will roll forward and back just fine. The problem is Windows' World Domination Conspiracy. Well, sorta... Microsoft doesn't give hoot what anybody else does, they do what they do and that's that (like or lump it, one might say).
Well, Winders is going to screw with the hardware clock and that's that. Doing what you're doing (booting Windows, let it do its thing, shut down and boot Linux, well, that's a solution, not elegant but...).
KDE does not set the system clock, it reads it (the system clock is set from the hardware clock during boot). It also reads your system settings (such as those you did with timeconfig -- you did that during installation of Slackware). Some years ago, when I was dual booting Slackware and XP, I just shut off the XP daylight time thing and that was that (and, frankly, I didn't use XP enough to get too excited about what time it said).

The "best" solution? Get VirtualBox, load XP into that and problem solved -- VirtualBox won't allow a Windows guest operating system fiddle with the hardware clock. But that's a whole different story.

The problem is living in two radically different worlds and a good fix is to simply set your hardware clock to local time (in Linux) and shut off Windows' daylight time adjustment; the clocks will display correctly (even if Windows doesn't say DST).

Hope this helps some.

It is possible to make Windows use UTC time for the hardware clock (instead of local time). I had this setup when I used to dual-boot between Windows and Slackware.

There is a registry setting in Windows. Just Google something like "windows PC UTC clock".

And that can be a real PITA. I once tried that and it didn't work out at all on an XP box. Your mileage may vary, but be sure to make a backup of that registry key or write down the old value in case you have to change it back.