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


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

time problem

Started by"Bill Cunningham" <nospam@nspam.invalid>
First post2014-10-25 18:24 -0400
Last post2014-10-28 14:24 +0000
Articles 20 on this page of 42 — 17 participants

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 2 of 3 — ← Prev page 1 [2] 3  Next page →


#12525

FromWilliam Unruh <unruh@invalid.ca>
Date2014-10-27 13:58 +0000
Message-ID<m2lj30$7ls$2@dont-email.me>
In reply to#12517
On 2014-10-27, 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.
>
> 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.

Arrgh. No. SEt /etc/hardwareclock to utc, NOT /etc/localtime.
/etc/localtime tells the system how to translate the reading from
whatever( which is in utc) to the localtime. You want that if you like
in the EST/EDT timezone. 


>

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


#12528

FromRich <rich@example.invalid>
Date2014-10-27 18:04 +0000
Message-ID<m2m1el$3oh$1@dont-email.me>
In reply to#12525
William Unruh <unruh@invalid.ca> wrote:
> On 2014-10-27, 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.
> >
> > 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.

> Arrgh. No. SEt /etc/hardwareclock to utc, NOT /etc/localtime.
> /etc/localtime tells the system how to translate the reading from
> whatever( which is in utc) to the localtime. You want that if you like
> in the EST/EDT timezone. 

Oops... Good catch.  Yes, that should have been two /etc/hardwareclock
items above.

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


#12493

FromWilliam Unruh <unruh@invalid.ca>
Date2014-10-26 16:13 +0000
Message-ID<m2j6j2$tma$1@dont-email.me>
In reply to#12487
On 2014-10-26, JohnF <john@please.see.sig.for.email.com> wrote:
> 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.

They are using "PC" to mean "Windows". Whoever set up that timeconfig 
program was an idiot. 
You might want to set a bugreport to your distro, because that certainly
is a bug. 

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

Nope. They read the /etc/localtime and translate the readings from those
clocks to whatever that file says you want your time to be. 

If date says UTC, that means that either /etc/localtime has disappeared
or has been corrupted, or was not there on boot. Is /etc/localtime a
link or a copy of the file from zoneinfo? If it is a link, instead make
it a copy
rm /etc/localtime
cp /usr/share/zoneinfo/EST5EDT /etc/localtime
or whatever you are using for you zoneinfo file. 

It can be that at bootup, /usr/share is not available, and the time then
defaults to 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 .

hwclock has nothing to do with the timezone issues. 

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

??? No, using --utc tells the program that your hardware clock is in
utc, and this is the default for that program. 
hwclock will read the hardware (not system) clock and use /etc/localtime
to translate that to local time. 

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


#12565

FromChick Tower <c.tower@deadspam.com>
Date2014-10-31 03:30 +0000
Message-ID<m2uvp3$184$1@dont-email.me>
In reply to#12493
On 2014-10-26, William Unruh <unruh@invalid.ca> wrote:
> They are using "PC" to mean "Windows". Whoever set up that timeconfig 
> program was an idiot. 
> You might want to set a bugreport to your distro, because that certainly
> is a bug. 

I seriously doubt that.  It's more likely a configuration error on the
part of the user.  I am using the same version of the distro John uses,
and I can see the timeconfig script was last modified in October of
2000, other than updating timezone information, and the last of those
was in December of 2012.  Do you really think such an obvious bug in an 
installation script would exist that long without being fixed?
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

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


#12492

FromWilliam Unruh <unruh@invalid.ca>
Date2014-10-26 16:02 +0000
Message-ID<m2j5u1$ot4$2@dont-email.me>
In reply to#12485
On 2014-10-26, 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
> remains edt for a few days, then suddenly I notice
> iot's utc. What could be causing that?

Why in the world would you set your system to localtime? That is simply
begging for trouble ( and you get it). 
Note the the hardware clock is not used by linux at all except for boot. 
Do you regularly boot this machine? How do you notice it's UTC? 

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


#12503

FromAndreas Kohlbach <oct14.5.ankman@spamgourmet.com>
Date2014-10-26 17:48 -0400
Message-ID<87zjci4i5l.fsf@usenet.ankman.de>
In reply to#12492
William Unruh wrote on 26. October 2014:
>
> On 2014-10-26, 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
>> remains edt for a few days, then suddenly I notice
>> iot's utc. What could be causing that?
>
> Why in the world would you set your system to localtime? That is simply
> begging for trouble ( and you get it).

That is when you also use Windows. Windows cannot really deal with time
zones. If you set it to run in UTC/GMT (and not live in the UK) you will
have an offset to your local time. Even if you set a time zone in
Windows.

> Note the the hardware clock is not used by linux at all except for boot. 

I guess some Linux distributions also write the RTC on shutdown.
-- 
Andreas

I wish my grass was emo. Then it would cut itself.

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


#12506

FromWilliam Unruh <unruh@invalid.ca>
Date2014-10-26 21:58 +0000
Message-ID<m2jqqp$9ov$2@dont-email.me>
In reply to#12503
On 2014-10-26, Andreas Kohlbach <oct14.5.ankman@spamgourmet.com> wrote:
> William Unruh wrote on 26. October 2014:
>>
>> On 2014-10-26, 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
>>> remains edt for a few days, then suddenly I notice
>>> iot's utc. What could be causing that?
>>
>> Why in the world would you set your system to localtime? That is simply
>> begging for trouble ( and you get it).
>
> That is when you also use Windows. Windows cannot really deal with time
> zones. If you set it to run in UTC/GMT (and not live in the UK) you will
> have an offset to your local time. Even if you set a time zone in
> Windows.
>
>> Note the the hardware clock is not used by linux at all except for boot. 
>
> I guess some Linux distributions also write the RTC on shutdown.

Yes. If you run ntpd it will also write the rtc every 11 min. 

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


#12515

From"Nuno J. Silva (aka njsg)" <njsg@invalid.invalid>
Date2014-10-27 08:47 +0000
Message-ID<m2l0qt$lqk$1@news.datemas.de>
In reply to#12503
On 2014-10-26, Andreas Kohlbach <oct14.5.ankman@spamgourmet.com> wrote:
> William Unruh wrote on 26. October 2014:
>>
>> On 2014-10-26, 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
>>> remains edt for a few days, then suddenly I notice
>>> iot's utc. What could be causing that?
>>
>> Why in the world would you set your system to localtime? That is simply
>> begging for trouble ( and you get it).
>
> That is when you also use Windows. Windows cannot really deal with time
> zones. If you set it to run in UTC/GMT (and not live in the UK) you will
> have an offset to your local time. Even if you set a time zone in
> Windows.

I do not think I've seen this problem. If I set Windows to use UTC in
the RTC, it will still respect the timezone and make the conversion, but
it will treat the UTC as RTC. But it won't show any offset to my local
time (I live in EEST/EET, so we're always off from UTC+0 by 4/3 hours).

(In order to set Windows to use UTC in the RTC, the DWORD registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
must exist with the value "1".)


>
>> Note the the hardware clock is not used by linux at all except for boot. 
>
> I guess some Linux distributions also write the RTC on shutdown.


-- 
Nuno Silva (aka njsg)
Helsinki, Finland

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


#12532

FromAndreas Kohlbach <oct14.5.ankman@spamgourmet.com>
Date2014-10-27 17:20 -0400
Message-ID<87sii96wgo.fsf@usenet.ankman.de>
In reply to#12515
Nuno J. Silva (aka njsg) wrote on 27. October 2014:
>
> On 2014-10-26, Andreas Kohlbach <oct14.5.ankman@spamgourmet.com> wrote:
>>>
>>> Why in the world would you set your system to localtime? That is simply
>>> begging for trouble ( and you get it).
>>
>> That is when you also use Windows. Windows cannot really deal with time
>> zones. If you set it to run in UTC/GMT (and not live in the UK) you will
>> have an offset to your local time. Even if you set a time zone in
>> Windows.
>
> I do not think I've seen this problem. If I set Windows to use UTC in
> the RTC, it will still respect the timezone and make the conversion, but
> it will treat the UTC as RTC. But it won't show any offset to my local
> time (I live in EEST/EET, so we're always off from UTC+0 by 4/3 hours).

IIRC (Windows 2000 knowledge, might be outdated by now) if you are in a
country of continental Europe, say France. And you set your RTC to
UTC. When you then boot Windows and set the timezone for France (CET,
which is UTC +1 or 2 hours in summer) Windows will treat this as the only
time it knows. On shutdown it will set the RTC plus or minus the offset
the timezone you configure has.

> (In order to set Windows to use UTC in the RTC, the DWORD registry key
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
> must exist with the value "1".)

I think there was a menu option "UTC" in Windows 2000.
-- 
Andreas

I wish my grass was emo. Then it would cut itself.

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


#12511

FromJohnF <john@please.see.sig.for.email.com>
Date2014-10-27 04:45 +0000
Message-ID<m2kim2$q6b$2@reader1.panix.com>
In reply to#12492
William Unruh <unruh@invalid.ca> wrote:
> On 2014-10-26, 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
>> remains edt for a few days, then suddenly I notice
>> iot's utc. What could be causing that?
> 
> Why in the world would you set your system to localtime?
From your other followup, I guess you've already read the answer...
the instructions emitted when running timeconfig seem to be
recommending that. It's of no specific interest to me either way,
except insofar as files get timestamped correctly,
and it'd be kind of nice if date displayed the same values
as my "standalone clocks".

> That is simply begging for trouble ( and you get it). 
> Note the the hardware clock is not used by linux at all except for boot. 
> Do you regularly boot this machine? How do you notice it's UTC? 
Yes, booted every day. I don't notice utc specifically;
I notice date is wrong and files are timestamped wrong.
And they're both four hours ahead, corresponding to utc/edt difference.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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


#12482

From"Bill Cunningham" <nospam@nspam.invalid>
Date2014-10-25 21:08 -0400
Message-ID<m2hhit$1c0$1@speranza.aioe.org>
In reply to#12480
"philo " <philo@privacy.net> wrote in message 
news:m2hgmc$898$1@dont-email.me...
> Set to local time if it's on UTC (which I think is the default)

Yes I see now it is the default.

Bill

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


#12489

Fromphilo  <philo@privacy.net>
Date2014-10-26 07:15 -0500
Message-ID<m2iolp$e34$1@dont-email.me>
In reply to#12482
On 10/25/2014 08:08 PM, Bill Cunningham wrote:
> "philo " <philo@privacy.net> wrote in message
> news:m2hgmc$898$1@dont-email.me...
>> Set to local time if it's on UTC (which I think is the default)
>
> Yes I see now it is the default.
>
> Bill
>
>



Yep I had the identical situation on my dual boot machine and that fixed it.

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


#12488

FromBalwinder S Dheeman <bdheeman.SANSPAM@outlook.com>
Date2014-10-26 14:08 +0530
Message-ID<m2ibur$rrn$1@speranza.aioe.org>
In reply to#12475
On 10/26/2014 03:54 AM, 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.

Please check
http://yourmacguy.wordpress.com/2008/08/09/boot-camp-clock-sync/

The Mac OS (FreeBSD indeed) and Unix/Linux systems prefer and work
better by setting the RTC (hardware clock) to UTC, whereas almost all
variants of Winodws saves the time (usually during shutdown) as local
time to RTC :(

-- 
Balwinder S "bdheeman" Dheeman (http://bdheeman.BlogSpot.in/)
"Working together, works! The proof is GNU/Linux and F/LOSS Projects;
Do you too voluntarily work on or contribute to making any difference?"

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


#12508

FromCharlie Gibbs <cgibbs@kltpzyxm.invalid>
Date2014-10-27 03:15 +0000
Message-ID<m2kdcg01o2a@news6.newsguy.com>
In reply to#12488
On 2014-10-26, Balwinder S Dheeman <bdheeman.SANSPAM@outlook.com> wrote:

> On 10/26/2014 03:54 AM, 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.
>
> Please check
> http://yourmacguy.wordpress.com/2008/08/09/boot-camp-clock-sync/
>
> The Mac OS (FreeBSD indeed) and Unix/Linux systems prefer and work
> better by setting the RTC (hardware clock) to UTC, whereas almost all
> variants of Winodws saves the time (usually during shutdown) as local
> time to RTC :(

'zackly.  So if you must run Windoze from time to time, run it under
VirtualBox.  Then you always have your Linux tools handy, and your
hardware clock doesn't get screwed up.  (Mind you, I still occasionally
dual-boot my laptop into Windows, but only because there isn't a Linux
port of The Stanley Parable yet, and it won't run under VirtualBox.)

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

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


#12491

FromWilliam Unruh <unruh@invalid.ca>
Date2014-10-26 15:53 +0000
Message-ID<m2j5e4$ot4$1@dont-email.me>
In reply to#12475
On 2014-10-25, Bill Cunningham <nospam@nspam.invalid> 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.

Sounds like timezone problems. What did you tell Linux your system time
was on? Are you running ntpd or some other time program? What time zone
are you in? 

>
> Bill
>
>

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


#12500

FromJames Moe <jimoeDESPAM@sohnen-moe.com>
Date2014-10-26 14:01 -0700
Message-ID<n7GdnV6cL-Og_NDJnZ2dnUU7-QmdnZ2d@giganews.com>
In reply to#12475
On 10/25/2014 03: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.
> 
  Enable NTP on both systems.

-- 
James Moe
jmm-list at sohnen-moe dot com

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


#12513

FromMichael Baeuerle <michael.baeuerle@stz-e.de>
Date2014-10-27 07:59 +0000
Message-ID<AABUTfqTA9sAAAuT.A1.flnews@WStation3.stz-e.de>
In reply to#12500
James Moe wrote:
> 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.
> > 
>   Enable NTP on both systems.

Don't forget to step the time (using ntpdate or something like that)
before starting the NTP daemon in this case. Otherwise the time
difference may be too large and the NTP daemon may fail to synchronize
with the time server.

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


#12522

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2014-10-27 13:31 +0100
Message-ID<m2ldvq$dr6$1@news1.tnib.de>
In reply to#12513
Michael Baeuerle <michael.baeuerle@stz-e.de> wrote:
>James Moe wrote:
>> 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.
>> > 
>>   Enable NTP on both systems.
>
>Don't forget to step the time (using ntpdate or something like that)
>before starting the NTP daemon in this case. Otherwise the time
>difference may be too large and the NTP daemon may fail to synchronize
>with the time server.

Big myth. see iburst in /etc/ntp.conf.

Greetings
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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


#12536 — "iburst" option of ntpd (was: time problem)

FromMichael Baeuerle <michael.baeuerle@stz-e.de>
Date2014-10-28 08:23 +0000
Subject"iburst" option of ntpd (was: time problem)
Message-ID<AABUT0ypgcAAAAnS.A1.flnews@WStation3.stz-e.de>
In reply to#12522
Marc Haber wrote:
> Michael Baeuerle wrote:
> > James Moe wrote:
> > > 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.
> > > 
> > >   Enable NTP on both systems.
> > 
> > Don't forget to step the time (using ntpdate or something like that)
> > before starting the NTP daemon in this case. Otherwise the time
> > difference may be too large and the NTP daemon may fail to synchronize
> > with the time server.
> 
> Big myth. see iburst in /etc/ntp.conf.

Looks like they are currently integrating the functions of ntpdate into
ntpd (-q option).

Are you sure that "iburst" alone can replace ntpdate in any case?
For me it looks like that the -g and -q options of ntpd are the intended
replacements for ntpdate (and "iburst" alone is simply a shorter initial
poll interval to speed up the synchronization process).

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


#12537 — Re: "iburst" option of ntpd (was: time problem)

FromMarc Haber <mh+usenetspam1118@zugschl.us>
Date2014-10-28 10:14 +0100
SubjectRe: "iburst" option of ntpd (was: time problem)
Message-ID<m2nmpu$dqm$1@news1.tnib.de>
In reply to#12536
Michael Baeuerle <michael.baeuerle@stz-e.de> wrote:
>Are you sure that "iburst" alone can replace ntpdate in any case?
>For me it looks like that the -g and -q options of ntpd are the intended
>replacements for ntpdate (and "iburst" alone is simply a shorter initial
>poll interval to speed up the synchronization process).

Debian starts the ntpd with -g, and has iburst in its server
statements in the configuration, has no ntpdate, and everything works
just fine.

So, I stand corrected, it's the combination of -g and iburst that
makes things purr.

Greetings
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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


Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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


csiph-web