Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!panix!not-for-mail From: JohnF Newsgroups: comp.os.linux.misc Subject: Re: time problem Date: Sun, 26 Oct 2014 07:11:09 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 88 Message-ID: References: NNTP-Posting-Host: panix3.panix.com X-Trace: reader1.panix.com 1414307469 24490 166.84.1.3 (26 Oct 2014 07:11:09 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Sun, 26 Oct 2014 07:11:09 +0000 (UTC) User-Agent: tin/2.0.0-20110823 ("Ardenistiel") (UNIX) (NetBSD/6.1.4 (i386)) Xref: csiph.com comp.os.linux.misc:12487 Rich wrote: > JohnF wrote: >> Keith Keller wrote: >> > Bill Cunningham wrote: >> >> "philo " wrote in message >> >>> >> >>> Set to local time if it's on UTC (which I think is the default) >> >> >> >> I try hwclock with the -w and -s switch. They don't seem to do >> >> anything. The old Linux's used an ntp server to get the time. >> > >> > The new linux distributions use ntp to get the time. The hardware >> > clock and NTP are two different issues (I think this was posted >> > recently). >> > >> > As many many people have suggested in this thread, either tell your >> > Windows box to use UTC (preferred if possible) or tell your linux >> > to use localtime. keith > >> I've been having pretty much the same problem with slackware 14.1, >> and am not running windows in any way, shape, or form on this box. >> Every couple of days, some app seems to reset the hwclock to UTC. But >> date show blah-blah EDT 2014, and there's no... >> diff /etc/localtime /usr/share/zoneinfo/US/Eastern >> ...differences. I set the date, clock -w it, and it > Which "it"? Output from 'date' or the HWclock contents? Thanks for followup and info, Rich. "It" is from 'date'. Now that, thanks to your remarks, I'm researching it (the problem) better, I realize that 'date' isn't sufficient info. >> remains edt for a few days, then suddenly I notice it's utc. > Which "it"? Output from 'date' or the HWclock contents? As above, 'date'. >> What could be causing that? > Do you reboot between the time you set the HWclock, > and the instant you find UTC showing up somewhere? Well, yes, but "find" is the operative word there. I'm not sure when it "actually happens" (during boot or otherwise) because I don't often notice the date. Mostly when I'm doing something like ls -alt|less to double-check what I've been working on, and notice it's screwy. > If so, what is the contents of your /etc/hardwareclock file? That's localtime (and some #comments). > Since you say you are not running windows, then quit trying to store > the hardware clock as localtime, have it set to UTC, and everything > will be fine. You'll still see localtime everywhere anyway. Okay, thanks. > If /etc/hardwareclock already say UTC, leave it alone. If not, change > "localtime" to UTC in the file, and quit trying to have the HWclock be > local. Okay, done. Note: I ran timeconfig to make the change (as suggested by those #comments), and it says about localtime that "this is how most PCs are set up". But I nevertheless changed /etc/hardwareclock to UTC as you suggested. > Then, set the system time if/when you need to adjust things (use the > date command, it also "sets/changes" the time). And then save the > result into the hardware clock with: > hwclock --utc --systohc Okay, done, but 'date' and 'hwclock -r' both still say the same numerical time, and both say EDT. I'm guessing I have to kill -HUP something, but I couldn't guess which pid from ps ax. I'll have to try a reboot (but that's tough to do in the middle of a reply:). > Or, setup an ntp client to keep your clocks synced with the ntp system > on the internet, and just let the Slackware 14.1 rc.d scripts save the > system time to the hardware clock when you do shutdown. Didn't want to do that, but looked at those scripts for some clue about the process mentioned above. But all I could find was your preceding instructions hwclock --utc --systohc in rc.0 . > Just always give the 'hwclock' command the --utc flag and it will > translate the time from the hwclock into your local time for you when > you want to view/reset the hwclock. Okay, as above, doesn't seem to be doing exactly that now, but I'll try a reboot and see if some process or other initializes itself with the new /etc/hardwareclock contents. Thanks for the help, -- John Forkosh ( mailto: j@f.com where j=john and f=forkosh )