Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #12510

Re: time problem

Show key headers only | View raw

Rich <rich@example.invalid> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>> Rich <rich@example.invalid> wrote:
>> > JohnF <john@please.see.sig.for.email.com> wrote:
>> >> 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'.
> 
> That is quite strange.  Provided you've got /etc/localtime set to your
> correct TZ file (and your "diff" line indicates you do (although "cmp"
> is the better choice than diff on binary files) then the output from
> date should always show as local time.  Now, the actual value "with a
> EDT/EST suffix" may be incorrect, but that is different than date
> outputting a string saying "UTC" (which is what your statement means
> when I read it).

Thanks again, Rich. cmp, as expected, also shows no differences.
date has an EDT suffix, unless run as date --utc as shown below,
or unless (for an experiment) I run timeconfig and change localtime
to GMT, in which case suffixes are GMT. Right now, as I write this,
timeconfig has localtime set to EDT, /etc/hardwareclock has UTC,
box was booted that way, and outputs are...
date                   Sun Oct 26 23:29:35 EDT 2014
date --utc             Mon Oct 27 03:30:03 UTC 2014
hwclock -r             Sun 26 Oct 2014 11:30:31 PM EDT  -0.859741 seconds
hwclock -r --utc       Sun 26 Oct 2014 11:31:12 PM EDT  -0.359708 seconds
hwclock -r --localtime Mon 27 Oct 2014 03:31:45 AM EDT  -0.312837 seconds
Seems to be a hwclock glitch (I don't suppose it's relevant to
my particular problem) that suffixes are always EDT, whereas
date has edt time and EDT suffix, but date --utc has utc time and
UTC suffix, which is what I'd expect. But hwclock -r --localtime
shows correct utc numerical value, but followed by an EDT suffix.

> The difference is:
>  o Date outputs a time string, suffixing EST/EDT, and the time string is
>    correct for current EST/EDT.
Yes, this is what's happening right now, as illustrated above, and ...

>  o Date outputs a time string, suffixing EST/EDT, and the output string
>    is _incorrect_ for current EST/EDT, but would be a correct UTC time
>    string.
...Yes, this is what happens when date goes screwy: suffix remains EDT,
but numerical value corresponds to utc (and day/date advance, too, if
it's locally close to, but before, midnight). Unfortunately, I did not
know enough to try date --utc with screwy clock, but will try that next
time it happens.

>> >> 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.
> 
> To track things like this down, you may need to do one of several
> things (and may need to do them all):
>  1) always check the output from 'date' just before a shutdown, and
>     just after the next reboot and compare the values
>  2) have some small clock visible on your desktop that displays
>     current time (including the EST/EDT) value that you can "keep an eye
>     on".
> Item #2 above can be "simulated" by running this in an xterm/rxvt
> (actually any terminal) window:
>     while true ; do date ; sleep 1 ; done
> It will output one line per second, with the current values from the
> date command.  Change the "1" in "sleep 1" to other values for longer
> delays, the "1" means wait one second.

Thanks, Rich. Actually, I'm using fvwm2, with some ~/.fvwm/
modifications, and it's already displaying an xclock.
What I have to do is actually look at it more regularly :)

>> > 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.
> 
> That "comment" is probably written with the assumption that "most PCs"
> are, or will, also boot windows, and convincing windows to use UTC for
> the hardware clock is quite a bit more trouble than having Linux
> accomodate microsofts brain damage. Since you indicate you never run
> windows on the machine, there's no point in accomodating microsoft
> idiocy.

Yeah, during install I just followed what seemed to be their
recommendation. And never had any problems with previous
slackware releases (though I jumped from 12.2 to 14.1, so
can't comment on the intermediate ones). So never gave it
much thought.

>> > 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:).
> 
> Actually, modern hwclock's attempt to "remember" what was last used and
> try to reuse that last value, from the Slackware 14.1 hwclock man page:
>  -u, --utc
>  --localtime
>     Indicates that the Hardware Clock is kept in Coordinated Universal
>     Time or local time, respectively.  It is your choice whether to
>     keep your clock in UTC or local time, but nothing in the clock
>     tells which you've chosen.  So this option is how you give that
>     information to hwclock.
>        If you specify the wrong one of these options (or specify neither
>     and take a wrong default), both setting and querying of the
>     Hardware Clock will be messed up.
>        If you specify neither --utc nor --localtime, the default is
>     whichever was specified the last time hwclock was used to set the
>     clock (i.e. hwclock was successfully run with the --set,
>     --systohc, or --adjust options), as recorded in the adjtime file. 
>     If the adjtime file doesn't exist, the default is UTC time.
> Older hwclocks did not try to "remember" and I just got into the habit
> of always including --utc on any use I made of hwclock.

Thanks for the additional info. I'd actually looked at man hwclock,
but got that -r --localtime versus --utc backwards. I'd just expected
--utc to display UTC, but it's apparently --localtime which does that.
I didn't read it carefully enough the first time to realize my
expectations were wrong. So my preceding remarks that hwclock -r
was showing edt were based on incorrectly trying hwclock -r --utc.

>> > 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 .
> 
> Why not?  It means your computer clock will always be set correctly.

I don't always have the box on the internet. 90% of the time I'm
just editing stuff, and the box is standalone (except for my lan
with some NAS's for backup). Box almost always boots standalone.

> If you don't want to try setting up the ntp deamons that come with
> Slackware, the Chrony package
> (http://slackbuilds.org/repository/14.1/network/chrony/) provides a
> somewhat easier to setup deamon to sync to ntp time.  You'll still have
> to read the docs. to set it up properly however. 

Clock oscillator accuracy is more than enough for my purposes,
which are really only that edited files be timestamped correctly.
I want to ls -alt and see what I've been working on.
If clock jumps ahead and I fix it when I notice it,
then there's a four hour window (for EDT) where ls -alt is
out of order. I can live with that if necessary, but
was hoping there's an easy explanation/fix, especially since
earlier slackware releases never had this problem (as far as
I ever experienced). But situation now seems to be more
complicated than I expected. Next time it happens (I wish I
knew how to reproduce it at will), I'll be better able to
document the machine state, which will maybe reveal the cause.

>> > 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.
> 
> Likely because of its "memory" effect from the man page.  It tries to
> be "helpful" and translate what is in the hardware into a value that
> will make sense to you viewing it (i.e., into your local time if it
> "remembers" you set the hwclock to UTC. If you want to read the actual
> hwclock value without any time translation, just give hwclock the
> --localtime option when you _read_ the clock and you'll see the actual
> contents of the clock.
>    I.e., you can interpret --utc as "translate hwclock time to/from my
> actual local time value when I set/read the clock" and --localtime as
> "show me the raw contents of the clock, with no time translations". 
> Because in effect that is exactly what those two options do under the
> hood.

Yeah, as above, I'd misread/misunderstood the manpage, thinking
--localtime would do the translation (still seems to me like that
would be the natural interpretation, but I'm not complaining:).
Thanks again, Rich,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

time problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-25 18:24 -0400
  Re: time problem Grant <omg@grrr.id.au> - 2014-10-26 11:02 +1100
    Re: time problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-25 20:30 -0400
  Re: time problem Baho Utot <baho-utot@columbus.rr.com> - 2014-10-25 20:06 -0400
  Re: time problem philo  <philo@privacy.net> - 2014-10-25 19:53 -0500
    Re: time problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-25 21:02 -0400
      Re: time problem Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2014-10-25 18:20 -0700
        Re: time problem JohnF <john@please.see.sig.for.email.com> - 2014-10-26 03:31 +0000
          Re: time problem Rich <rich@example.invalid> - 2014-10-26 05:36 +0000
            Re: time problem JohnF <john@please.see.sig.for.email.com> - 2014-10-26 07:11 +0000
              Re: time problem Rich <rich@example.invalid> - 2014-10-26 15:43 +0000
                Re: time problem JohnF <john@please.see.sig.for.email.com> - 2014-10-27 04:35 +0000
                Re: time problem Rich <rich@example.invalid> - 2014-10-27 10:22 +0000
                Re: time problem JohnF <john@please.see.sig.for.email.com> - 2014-10-27 12:03 +0000
                Re: time problem Rich <rich@example.invalid> - 2014-10-27 12:21 +0000
                Re: time problem William Unruh <unruh@invalid.ca> - 2014-10-27 13:54 +0000
                Re: time problem JohnF <john@please.see.sig.for.email.com> - 2014-10-27 05:01 +0000
                Re: time problem Rich <rich@example.invalid> - 2014-10-27 10:23 +0000
                Re: time problem JohnF <john@please.see.sig.for.email.com> - 2014-10-27 12:11 +0000
                Re: time problem Rich <rich@example.invalid> - 2014-10-27 12:30 +0000
                Re: time problem William Unruh <unruh@invalid.ca> - 2014-10-27 13:58 +0000
                Re: time problem Rich <rich@example.invalid> - 2014-10-27 18:04 +0000
              Re: time problem William Unruh <unruh@invalid.ca> - 2014-10-26 16:13 +0000
                Re: time problem Chick Tower <c.tower@deadspam.com> - 2014-10-31 03:30 +0000
          Re: time problem William Unruh <unruh@invalid.ca> - 2014-10-26 16:02 +0000
            Re: time problem Andreas Kohlbach <oct14.5.ankman@spamgourmet.com> - 2014-10-26 17:48 -0400
              Re: time problem William Unruh <unruh@invalid.ca> - 2014-10-26 21:58 +0000
              Re: time problem "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2014-10-27 08:47 +0000
                Re: time problem Andreas Kohlbach <oct14.5.ankman@spamgourmet.com> - 2014-10-27 17:20 -0400
            Re: time problem JohnF <john@please.see.sig.for.email.com> - 2014-10-27 04:45 +0000
    Re: time problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-10-25 21:08 -0400
      Re: time problem philo  <philo@privacy.net> - 2014-10-26 07:15 -0500
  Re: time problem Balwinder S Dheeman <bdheeman.SANSPAM@outlook.com> - 2014-10-26 14:08 +0530
    Re: time problem Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2014-10-27 03:15 +0000
  Re: time problem William Unruh <unruh@invalid.ca> - 2014-10-26 15:53 +0000
  Re: time problem James Moe <jimoeDESPAM@sohnen-moe.com> - 2014-10-26 14:01 -0700
    Re: time problem Michael Baeuerle <michael.baeuerle@stz-e.de> - 2014-10-27 07:59 +0000
      Re: time problem Marc Haber <mh+usenetspam1118@zugschl.us> - 2014-10-27 13:31 +0100
        "iburst" option of ntpd (was: time problem) Michael Baeuerle <michael.baeuerle@stz-e.de> - 2014-10-28 08:23 +0000
          Re: "iburst" option of ntpd (was: time problem) Marc Haber <mh+usenetspam1118@zugschl.us> - 2014-10-28 10:14 +0100
            Re: "iburst" option of ntpd (was: time problem) William Unruh <unruh@invalid.ca> - 2014-10-28 21:10 +0000
          Re: "iburst" option of ntpd Chris Davies <chris-usenet@roaima.co.uk> - 2014-10-28 14:24 +0000

csiph-web