SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by tb75252
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
Code:
su - (or sudo or log in as root)
cd /usr/local
mkdir patches
cd patches
wget ftp://ftp.osuosl.org/pub/slackware/slackware64-13.37/patches/packages/*
<wait a while>
upgradepkg *.t?z
And, what does date show you? Should look a lot like this (if you're in the Eastern time zone):
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.
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.)
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
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:
Code:
date
Wed Nov 7 08:43:58 EST 2012
So, yes, it did adjust itself at boot and, because it runs NTP, it sync up with external time sources:
Code:
ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 805 64 0 0.000 0.000 0.000
*69.50.219.51 209.51.161.238 2 u 9 64 377 1191.31 1349.18 60.099
+208.53.158.34 204.9.54.119 2 u 11 64 377 879.435 1063.19 303.372
+199.241.31.96 164.244.221.197 2 u 13 64 377 992.040 1129.18 202.910
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
Code:
su - (or sudo or log in as root)
# See what your hardware clock time is
hwclock
Wed 07 Nov 2012 09:36:28 AM EST -0.813113 seconds
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
Code:
hwclock --set --utc --date="11/07/2012 14:33:00"
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
Code:
su - (or sudo or log in as root)
sh /etc/rc.d/rc.ntpd start
<wait about five minutes>
nptq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 86m 64 0 0.000 0.000 0.000
+69.50.219.51 209.51.161.238 2 u 90 128 377 1431.81 -55.584 32.071
*208.53.158.34 204.9.54.119 2 u 120 128 377 1509.82 -181.12 22.081
+199.241.31.96 164.244.221.197 2 u 104 128 377 1700.70 -318.39 57.700
That display is for three pool servers where /etc/ntp.conf has these entries in the server section near the top of the file:
Code:
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
#server pool.ntp.org
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
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.
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?
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by tb75252
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...
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).
Quote:
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.
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...).
Quote:
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?
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).
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...
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".
Distribution: Slackware64 14.2 and current, SlackwareARM current
Posts: 1,644
Rep:
Quote:
Originally Posted by regis_n_bits
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.