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

Groups > comp.os.linux.misc > #12475 > unrolled thread

time problem

Back to article view | Back to comp.os.linux.misc

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#12475 — time problem

    Everytime I log onto Fedora 20 I am finding that when I go back to 
windows the time is 4 hours ahead. There's something wrong somewhere. It's 
not right on linux either. I hope it's not hardware.

Bill

[toc] | [next] | [standalone]

#12476

On Sat, 25 Oct 2014 18:24:18 -0400, "Bill Cunningham" <nospam@nspam.invalid> wrote:

>Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
>From: "Bill Cunningham" <nospam@nspam.invalid>
>Newsgroups: comp.os.linux.misc
>Subject: time problem
>Date: Sat, 25 Oct 2014 18:24:18 -0400
>Organization: Aioe.org NNTP Server

Maybe the fact that you dual boot windows?

One is local time, the other is UTC. They're four hours apart. 

Sort that out and problem will disappear.

Grant.

[toc] | [prev] | [next] | [standalone]

#12479

"Grant" <omg@grrr.id.au> wrote in message 
news:seeo4atttifh43kt4vjhnk7sdt22lvcv1p@4ax.com...
> On Sat, 25 Oct 2014 18:24:18 -0400, "Bill Cunningham" 
> <nospam@nspam.invalid> wrote:
>
>>Path: 
>>eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
>>From: "Bill Cunningham" <nospam@nspam.invalid>
>>Newsgroups: comp.os.linux.misc
>>Subject: time problem
>>Date: Sat, 25 Oct 2014 18:24:18 -0400
>>Organization: Aioe.org NNTP Server
>
> Maybe the fact that you dual boot windows?
>
> One is local time, the other is UTC. They're four hours apart.
>
> Sort that out and problem will disappear.

    When I installed it, it was set to local time. I used several operating 
system various linuxes, Unix, windows but I've never seen an installer 
anything like F20's installer. It seems to be very user unfriendly.

Bill

[toc] | [prev] | [next] | [standalone]

#12477

Bill Cunningham wrote:

>     Everytime I log onto Fedora 20 I am finding that when I go back to
> windows the time is 4 hours ahead. There's something wrong somewhere. It's
> not right on linux either. I hope it's not hardware.
> 
> Bill

You need to set linux to localtime or set win(whatever) to UTC.

[toc] | [prev] | [next] | [standalone]

#12480

On 10/25/2014 05:24 PM, Bill Cunningham wrote:
>      Everytime I log onto Fedora 20 I am finding that when I go back to
> windows the time is 4 hours ahead. There's something wrong somewhere. It's
> not right on linux either. I hope it's not hardware.
>
> Bill
>
>



Set to local time if it's on UTC (which I think is the default)

[toc] | [prev] | [next] | [standalone]

#12481

"philo " <philo@privacy.net> wrote in message 
news:m2hgmc$898$1@dont-email.me...
> On 10/25/2014 05:24 PM, Bill Cunningham wrote: 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.

Bill

[toc] | [prev] | [next] | [standalone]

#12483

On 2014-10-26, Bill Cunningham <nospam@nspam.invalid> wrote:
>
> "philo " <philo@privacy.net> wrote in message 
> news:m2hgmc$898$1@dont-email.me...
>> On 10/25/2014 05:24 PM, Bill Cunningham wrote: 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

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[toc] | [prev] | [next] | [standalone]

#12485

Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
> Bill Cunningham <nospam@nspam.invalid> wrote:
>> "philo " <philo@privacy.net> 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
remains edt for a few days, then suddenly I notice
it's utc. What could be causing that?
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#12486

JohnF <john@please.see.sig.for.email.com> wrote:
> Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
> > Bill Cunningham <nospam@nspam.invalid> wrote:
> >> "philo " <philo@privacy.net> 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?

> remains edt for a few days, then suddenly I notice it's utc.

Which "it"?  Output from 'date' or the HWclock contents?

> What could be causing that?

Do you reboot between the time you set the HWclock, and the instant you
find UTC showing up somewhere?

If so, what is the contents of your /etc/hardwareclock file?

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.

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.

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

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.

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.

[toc] | [prev] | [next] | [standalone]

#12487

Rich <rich@example.invalid> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>> Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>> > Bill Cunningham <nospam@nspam.invalid> wrote:
>> >> "philo " <philo@privacy.net> 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 )

[toc] | [prev] | [next] | [standalone]

#12490

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).

The difference is:

  Date outputs a time string, suffixing EST/EDT, and the time string is
  correct for current EST/EDT.

  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.

> >> 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.

> > 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.

> > 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.

> > 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.

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. 

> > 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.

[toc] | [prev] | [next] | [standalone]

#12510

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 )

[toc] | [prev] | [next] | [standalone]

#12516

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.

> > 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 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.  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, 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".

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, 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.

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).

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.

[toc] | [prev] | [next] | [standalone]

#12518

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 )

[toc] | [prev] | [next] | [standalone]

#12520

JohnF <john@please.see.sig.for.email.com> wrote:

> 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.

You can still use "date" to set Linux's system time.

And you can still use hwclock (note, no 'clock' command) to set the
hardware clock from the system time.  Just always give it the --utc
switch when you ask it to set the hardware from the system (the "write"
option) and things will be good.

> But I'll wait to see what happens next time I do it.
> Maybe that --utc switch will automatically adjust the clock -w
> effect,

Yes, giving hwclock the --utc flag means it will put the correct
physical H:M:S values into the hardware clock.

> >> > 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 |
>      +--------+                   +------------+

Technically, given the above diagram, when you do power it up and talk
to the "internet" from "computers" via "big GB switch" you are actually
"using it's rounter functions".  In that arrangement, it is acting as a
"router" for your local lan.

> 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.

No, no, no.....

Don't try to overthink it.  The usage is actually simple:

  If /etc/hardwareclock says "UTC", then always give the hwclock
  command the --utc flag when you use hwclock to set/read the hardware.

  If /etc/hardwareclock says "localtime", then always give the hwclock
  command the --localtime flag when you use hwclock to set/read the
  hardware.

You don't have to concern yourself with when offsets get
added/subtracted if you do the above.  The developer writing hwclock
has to concern himself with those details, but you can ignore them.

And, given that Linux/Unix'es work best from a UTC basis, just set
/etc/hardwareclock to say UTC, and always give the --utc flag to the
hwclock command, and everything should be ok.

[toc] | [prev] | [next] | [standalone]

#12524

On 2014-10-27, 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

I do not know what the time was from your wristwatch but I assume it was
3:30 AM
This says that you re 4 hrs slow of UTC, and the hardware clock (rtc) is
set to localtime,

> 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 hardware clock has no suffixes. It is the hwclock program that
provices that. Your rtc is on localtime, and when you tell the program
to interpret the time as "localtime" it does so correctly. If you tell
it to interpret it as utc, (which is does by default) reads teh rtc,
translates that time to localtime and gives something 4 hrs off. 
Note tht the meaning of --utc is different for the date command and for
the hwclock command. For the date command it means-- Do not translate
the system time read from the system (the system clock is ALWAYS in utc) 
For the hwclock command it means-- the rtc's time is stored in utc.

Ie, it is NOT a glitch.

>
>> 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,

Nothing screwy. Your hardware clock is stored in localtime. But
sometimes you tell it to pretend that time is utc and sometimes
localtime.

>
> 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.

Somewhere you told it that the rtc was in localtime. 


>
> 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.

No. Those say NOTHING about the display. They tell the program how to
interpret the time read from the rtc. It always displays that time
translated by /etc/localtime.

> 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.

You still did not read it carefully.

[toc] | [prev] | [next] | [standalone]

#12512

Rich <rich@example.invalid> wrote:
> <<big snip>>
> 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.

I think you maybe solved the problem. On a hunch, just noticed that
rc.ntpd had 755 permissions, and indeed ps ax|grep ntp shows
    727 ?  Ss  0:00 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
I must have inadvertantly told slackware's setup to run it
during install (which would also explain why previous releases
never exhibited the problem), and it's somehow been sporadically
messing stuff up ever since. Changed permissions (and kill'ed
this instance), so the problem's hopefully solved. No idea what,
exactly, ntpd might have been doing, but it'll hopefully stop now.
Thanks yet again,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#12517

JohnF <john@please.see.sig.for.email.com> wrote:
> Rich <rich@example.invalid> wrote:
> > <<big snip>>
> > 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.

> I think you maybe solved the problem. On a hunch, just noticed that
> rc.ntpd had 755 permissions, and indeed ps ax|grep ntp shows
>     727 ?  Ss  0:00 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
> I must have inadvertantly told slackware's setup to run it during
> install (which would also explain why previous releases never
> exhibited the problem), and it's somehow been sporadically messing
> stuff up ever since. Changed permissions (and kill'ed this instance),
> so the problem's hopefully solved. No idea what, exactly, ntpd might
> have been doing, but it'll hopefully stop now.

That would do it.

Having an /etc/hardwareclock file set as "localtime" and the ntpd
daemon running would cause exactly what you've been seeing.

Change /etc/localtime to UTC (as you've done, and leave it that way)
and you can keep ntpd running and always have the correct time.

[toc] | [prev] | [next] | [standalone]

#12519

Rich <rich@example.invalid> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
>> Rich <rich@example.invalid> wrote:
>> > <<big snip>>
>> > 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.
> 
>> I think you maybe solved the problem. On a hunch, just noticed that
>> rc.ntpd had 755 permissions, and indeed ps ax|grep ntp shows
>>     727 ?  Ss  0:00 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
>> I must have inadvertantly told slackware's setup to run it during
>> install (which would also explain why previous releases never
>> exhibited the problem), and it's somehow been sporadically messing
>> stuff up ever since. Changed permissions (and kill'ed this instance),
>> so the problem's hopefully solved. No idea what, exactly, ntpd might
>> have been doing, but it'll hopefully stop now.

> That would do it.
> Having an /etc/hardwareclock file set as "localtime" and the ntpd
> daemon running would cause exactly what you've been seeing.
Good to know there's (finally) a rational explanation.

> Change /etc/localtime to UTC (as you've done, and leave it that way)
> and you can keep ntpd running and always have the correct time.
Actually, after all this, I feel more like taking ntpd out back
and feeding it into the wood chipper (channeling the movie Fargo).
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#12521

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:
> >> > <<big snip>>
> >> > 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.
> > 
> >> I think you maybe solved the problem. On a hunch, just noticed that
> >> rc.ntpd had 755 permissions, and indeed ps ax|grep ntp shows
> >>     727 ?  Ss  0:00 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
> >> I must have inadvertantly told slackware's setup to run it during
> >> install (which would also explain why previous releases never
> >> exhibited the problem), and it's somehow been sporadically messing
> >> stuff up ever since. Changed permissions (and kill'ed this
> >> instance), so the problem's hopefully solved. No idea what,
> >> exactly, ntpd might have been doing, but it'll hopefully stop now.

> > That would do it.
> > Having an /etc/hardwareclock file set as "localtime" and the ntpd
> > daemon running would cause exactly what you've been seeing.

> Good to know there's (finally) a rational explanation.

> > Change /etc/localtime to UTC (as you've done, and leave it that
> > way) and you can keep ntpd running and always have the correct
> > time.

> Actually, after all this, I feel more like taking ntpd out back and
> feeding it into the wood chipper (channeling the movie Fargo).

It is not actually ntpd's fault.  Unix systems should always have their
physical clocks storing values that are UTC.  The translation into
human time zones happens when the humans ask "what time is it".

Ntpd is written assuming that the above is true.  That the clocks are
set with physical numbers that are UTC values.  The glitch was that the
actual numbers stored into the hardware by hwclock were physical
numbers after the conversion to local time (because you'd asked it to
do that in your old /etc/hardwareclock setting) while ntpd was setting
physical numbers that are valid UTC time values (as it rightfully should).

So the next time hwclock read in the values, it thought the values were
"local zone" values, and applied a conversion to produce what it
thought should be correct UTC values to put into the system clock.  The
result was a +4 hour discrepancy.


A good analagy is to think of it as imperial vs. metric measurments.

You have a numerical value.  It usually represents feet (localtime).
You want a value in meters (utc).  So you apply the conversion factor
for feet->meters.

But, if the number you read as "feet" is actually a measurment value
that is actually in "meters" already.  Applying the feet->meters
conversion factor will produce the wrong final value.

The above is what was going wrong with your times.  You were applying
"local->UTC" conversion to a numerical value that was already "UTC".

UTC + "local->UTC factor" ==> incorrect value.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web