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

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

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:
>> >> 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.
> 
> Actually, the above is all 100% exactly as I would expect the outputs
> to be with /etc/localtime set to US-Eastern.
> 
> What the "--localtime" switch to hwclock does is say "do not translate
> the hwclock value" (i.e., do not add/subtract any amount of time
> to/from from it). But, because the switch is "--localtime", hwclock
> appends what should be the proper localtime timezone characters to the
> end of the time string it outputs.
> 
> And this decision on the part of the author of hwclock is reasonable.
> Remember the name (and purpose) of --localtime. It means "the
> hours:minutes:seconds stored in the hardware are already translated to
> the _local_ timezone". So checking /etc/localtime to pick up the
> proper zone flag, and outputting that flag along with the
> hours:minutes:seconds stored in the hardware is the right thing to do
> based upon what the --localtime flag means. You'd be upset with a
> hardware clock in localtime if the --localtime output from hwclock said
> UTC. Remember, the hardware clock _does not_ store timezone
> information. It just stores an hours:minutes:seconds value. So
> hwclock (unless you tell it otherwise) has no way to discern an H:M:S
> value in localtime from H:M:S as UTC using only the data in the
> hardware.

I guess it's all moot now, based on my own ntpd stupidity (not sure
if netiquette prohibits me from insulting myself:) discussed in other
post. But based on your above description, specifically the part
"...It just stores an hours:minutes:seconds value...", I'd think
hwclock -r should display only that, the stored values, not
followed by EDT or UTC or anything. So there'd be no --utc and
no --localtime switches at all. And no ambiguity -- what you see
is what it's got.
   But like I said earlier, I'm not complaining. Just grateful for
all the free software, and your help with it, and more than happy
to comply with the author's preferences.

>> > 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.
> 
> That tells me that somewhere, you are accidentially reading the
> hardware clock into the Linux system clock
     -------
     Yeah, based on subsequent ntpd post, I guess we now know
     where that "somewhere" is:)
     -------
> by using the --localtime
> flag, when the clock itself is storing an H:M:S value (remember, no
> stored "zone" in the hardware) that is really a UTC value.  That output
> from date is exactly what will occur by doing this:
>  hwclock --systohc --utc
> followed by this at some later point
>  hwclock --hctosys --localtime

>> 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 :)
> Double checking it for a bit will be good.

> I suspect what's been happening to you is that you've been your own
> worst enemy.
     "Don't beat yourself. That's the worst defeat you'll ever suffer."
     -- John Wooden (famous football coach)
> You had (until you recently changed it) Slackwares
> /etc/hardwareclock set as "localtime". You then manually "set" the
> hardware via hwclock --systohc --utc into UTC, without changing
> /etc/hardwareclock. Then, on next reboot, your output from date will
> be +4 hours ahead (or +5 once we flip back to EST).
> 
> I.e., you were unknowingly mixing apples and oranges.  Don't do that. 
> Decide on one setting for the hardware, and stick to it, and your
> troubles will likely go away. But "sticking to it" also entails
> setting /etc/hardwareclock to the setting you've picked to utilize. 
> UTC is best if there is no windows booting. So set /etc/hardwareclock
> to say the clock is in UTC, and always give hwclock the --utc flag
> whenever you read/write directly into the hardware.

Yeah, I'll keep /etc/hardwareclock UTC. I think this probably means
I can no longer just clock -w after date MMDDhhmm using edt time, but
rather have to separately hwclock --set --date="yyyy-mm-dd hh:mm:ss"
using utc time. But I'll wait to see what happens next time I do it.
Maybe that --utc switch will automatically adjust the clock -w effect,
like I think you may be suggesting below. An awful lot of thinking
required here just to set clocks:)

>> 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.
> 
> I'm also running 14.1, this machine's set with the hardware in UTC, and
> I seldom write to the hardware clock, but when I do, I _always_ use the
> --utc flag. Zero time issues from userland. See the "own worst enemy"
> and "mixing apples and oranges" from the above paragraphs.

>> 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.
> 
> The distinction is:
>  1) apply time transformation based upon local zone (--utc)
>  2) don't apply any time transformations            (--localtime)
> I.e., it is trying to help you out, by not forcing you to remember what
> your offset to/from UTC happens to be based upon the current date in
> your local zone.  Which, in and of itself, is a good thing.

>> > 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.
> 
> Does the "lan" not have a gateway to the internet on it?  If so, when
> the machine's on the "lan" it also has "internet access".

My broadband's a pretty slow verizon dsl, and the dsl modem's
powered down when not in use (I'm not using its router functions,
which are disabled). So the lan's on its own, for sure.
No gateway, per se. Everything's just plugged into a switch,
     +--------+     +---------+
     |        |-----|dsl modem|-----telephone line
     |        |     +---------+   +---------------+
     | big GB |-------------------|router with wap|
     | switch |     +---------+   +---------------+
     |        |-----|computers|
     |        |     +---------+   +------------+
     |        |-------------------| NAS's, etc |
     +--------+                   +------------+

> In my case, this box is also only network connected to the local "lan". 
> But downstairs in the basement there is another Linux machine that has
> one ethernet card connected to the "lan" and the other connected to
> "the internet". And it acts as the gateway between the lan in the
> 'interenet.  Every single machine on the local lan then gets internet
> access.  That box also runs an ntp server that syncs with the internet,
> and the lan side machines sync with it, and I've never had to set or
> reset a computer clock for going on 15-20 years now.
> 
>> > 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.
> 
> See the "apples vs. oranges" above. I really suspect you've been
> causing the "jumps" yourself unknowingly through manual use of hwclock
> in conflict with the /etc/hardwareclock setting.

Yeah, I guess unknowingly running ntpd counts as "unknowingly".

>> 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,
> 
> That's because hwclock interprets the flags from the viewpoint of the
> hardware, which is opposite to the viewpoint of userland.  For hwclocks
> viewpoint you have to read the man page carefully (reformatted
> slightly):
>  -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.  ...
> The flags say how to interpret what is the H:M:S value in the hardware.
>   o Interpreting the hardware value as --localtime means hwclock has to
>     add/subtract offsets to obtain the proper time to put into the Linux
>     system clock (because the system clock is intended to always be set
>     as UTC).
>   o Interpreting the hardware as --utc means no offsets need be
>     added/subtracted to put the hardware time into the Linux system timer.
> I.e., it is telling it how to interpret what is in the hardware.
> Once you realize, it makes sense.

Okay, so now the above seems to suggest clock -w --localtime
if /etc/localtime is EDT while /etc/hardwareclock is UTC,
whereas I (probably incorrectly) interpreted your earlier
remarks to suggest clock -w --utc for this situation.
But I'm sure that trying it every which way will quickly
resolve my mistake, one way or the other. Thanks again,
-- 
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