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

Groups > linux.debian.user > #195886 > unrolled thread

Correct: System Thinks Hardware Clock is UTC

Back to article view | Back to linux.debian.user

Contents

  Correct: System Thinks Hardware Clock is UTC Patrick Bartek <nemommxiv@gmail.com> - 2018-05-19 02:20 +0200
    Re: Correct: System Thinks Hardware Clock is UTC Ben Finney <bignose@debian.org> - 2018-05-19 02:40 +0200
      Re: Correct: System Thinks Hardware Clock is UTC Patrick Bartek <nemommxiv@gmail.com> - 2018-05-20 21:40 +0200
    Re: Correct: System Thinks Hardware Clock is UTC Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-19 03:00 +0200
      Re: Correct: System Thinks Hardware Clock is UTC Patrick Bartek <nemommxiv@gmail.com> - 2018-05-20 21:20 +0200
        Re: Correct: System Thinks Hardware Clock is UTC Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-20 21:50 +0200
          Re: Correct: System Thinks Hardware Clock is UTC Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-20 22:00 +0200
          Re: Correct: System Thinks Hardware Clock is UTC Patrick Bartek <nemommxiv@gmail.com> - 2018-05-21 01:10 +0200
    Re: Correct: System Thinks Hardware Clock is UTC David Wright <deblis@lionunicorn.co.uk> - 2018-05-19 04:00 +0200
      Re: Correct: System Thinks Hardware Clock is UTC Patrick Bartek <nemommxiv@gmail.com> - 2018-05-20 21:20 +0200
        Re: Correct: System Thinks Hardware Clock is UTC Steve McIntyre <steve@einval.com> - 2018-05-20 23:00 +0200
          Re: Correct: System Thinks Hardware Clock is UTC Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-20 23:40 +0200
        Re: Correct: System Thinks Hardware Clock is UTC Greg Wooledge <wooledg@eeg.ccf.org> - 2018-05-21 15:10 +0200
          Re: Correct: System Thinks Hardware Clock is UTC Patrick Bartek <nemommxiv@gmail.com> - 2018-05-21 17:20 +0200
        Re: Correct: System Thinks Hardware Clock is UTC Michael Stone <mstone@debian.org> - 2018-05-21 15:20 +0200
          Re: Correct: System Thinks Hardware Clock is UTC Felix Miata <mrmazda@earthlink.net> - 2018-05-21 16:00 +0200
            Re: Correct: System Thinks Hardware Clock is UTC Michael Stone <mstone@debian.org> - 2018-05-21 16:10 +0200
              Re: Correct: System Thinks Hardware Clock is UTC Felix Miata <mrmazda@earthlink.net> - 2018-05-21 23:30 +0200

#195886 — Correct: System Thinks Hardware Clock is UTC

Okay, it's my fault: I admit it. During the Base Only, Terminal-only
install of Stretch, I clicked UTC instead of Local for the hardware
clock time. Honestly, I thought the clock was set to UTC. Haven't
installed any other OS on this system since Wheezy 5 years ago. So, now
system time on Stretch is 7 hours earlier than it should be --
difference between my time zone and Greenwich.

I could use hwclock --set --date=<yadda yadda> with the --localtime
option, etc., to correct this but is there an easier way?

NOTE: I've already replace systemd as the init with sysvinit.  So, I
don't think systemd commands are appropriate. I've not installed ntp as
yet either.

Thanks

B

[toc] | [next] | [standalone]

#195887

Patrick Bartek <nemommxiv@gmail.com> writes:

> I could use hwclock --set --date=<yadda yadda> with the --localtime
> option, etc., to correct this but is there an easier way?

There is only one clock involved in this: the hardware clock.

By telling the operating system that your hardware clock is set to UTC,
you have told the operating system how to *render* the hardware clock's
time for your local time zone.

Setting the clock will set the hardware clock. By using a “set the
clock” tool, you will set the hardware clock — but the clock-setting
tool will take care of converting the time zone correctly.

I think the generally-applicable advice is correct: tell the OS that
your clock is set to UTC, and leave it to the operating system to figure
out the weirdness of time zones.

So I think you've done the right thing: tell the OS to keep the hardware
clock at UTC. Now you just need to tell it what the time is :-)

Assuming your machine is internet-connected, tell the operating system
to keep your hardware clock in sync with the Network Time Protocol, by
installing an NTP server. I can't recall what the default is; I use the
‘chrony’ package.

-- 
 \           “If you do not trust the source do not use this program.” |
  `\                                —Microsoft Vista security dialogue |
_o__)                                                                  |
Ben Finney

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

#195940

On Sat, 19 May 2018 10:37:39 +1000 Ben Finney <bignose@debian.org>
wrote:

> Patrick Bartek <nemommxiv@gmail.com> writes:
> 
> > I could use hwclock --set --date=<yadda yadda> with the --localtime
> > option, etc., to correct this but is there an easier way?
> 
> There is only one clock involved in this: the hardware clock.
> 
> By telling the operating system that your hardware clock is set to
> UTC, you have told the operating system how to *render* the hardware
> clock's time for your local time zone.
> 
> Setting the clock will set the hardware clock. By using a “set the
> clock” tool, you will set the hardware clock — but the clock-setting
> tool will take care of converting the time zone correctly.
>
> I think the generally-applicable advice is correct: tell the OS that
> your clock is set to UTC, and leave it to the operating system to
> figure out the weirdness of time zones.

Actually, the hardware clock has always been set to local time.  Had
to: Used to have Windows XP installed (this box is 11+ years old) as a
multi-boot with Linux, and as you know Windows needs the hardware
clock set to local to work correctly.  I've just keep it that way. .  

> So I think you've done the right thing: tell the OS to keep the
> hardware clock at UTC. Now you just need to tell it what the time
> is :-)

Actually, it's the other way around. hardware clock is local time, but
Stretch thinks it's UTC. (I have Wheezy on here to, but it's configured
correctly.)

Just going to use hwclock and the --localtime option to reset it.
Haven't been able to find any other way to do so.

> Assuming your machine is internet-connected, tell the operating system
> to keep your hardware clock in sync with the Network Time Protocol, by
> installing an NTP server. I can't recall what the default is; I use
> the ‘chrony’ package.

I alway install ntp, but I want everything timewise configured
appropriately before I do so.

Thanks for you advice.

B

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

#195888

On Fri, 18 May 2018 17:13:07 -0700 Patrick Bartek said:

> I could use hwclock --set --date=<yadda yadda> with the --localtime
> option, etc., to correct this but is there an easier way?

# dpkg-reconfigure tzdata

should do it, I think.

Regards
-- 
Abdullah Ramazanoğlu

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

#195938

On Sat, 19 May 2018 03:52:27 +0300 Abdullah Ramazanoğlu
<ar018@yahoo.com> wrote:

> On Fri, 18 May 2018 17:13:07 -0700 Patrick Bartek said:
> 
> > I could use hwclock --set --date=<yadda yadda> with the --localtime
> > option, etc., to correct this but is there an easier way?
> 
> # dpkg-reconfigure tzdata
> 
> should do it, I think.

tzdata sets the local time zone. Mine is correctly set  The
problem is the system "thinks" the hardware clock is set to UTC when
It's really set to local time. So, the time shown for my local time
zone is incorrect.

Anyway, thanks for your suggestion.

B

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

#195941

On Sun, 20 May 2018 12:10:01 -0700 Patrick Bartek said:

> On Sat, 19 May 2018 03:52:27 +0300 Abdullah Ramazanoğlu
> <ar018@yahoo.com> wrote:
> 
> > On Fri, 18 May 2018 17:13:07 -0700 Patrick Bartek said:
> >   
> > > I could use hwclock --set --date=<yadda yadda> with the --localtime
> > > option, etc., to correct this but is there an easier way?  
> > 
> > # dpkg-reconfigure tzdata
> > 
> > should do it, I think.  
> 
> tzdata sets the local time zone. Mine is correctly set  The
> problem is the system "thinks" the hardware clock is set to UTC when
> It's really set to local time. So, the time shown for my local time
> zone is incorrect.
> 
> Anyway, thanks for your suggestion.

You are welcome. :)

So, your original idea of using "hwclock --set --date --localtime" seems to be
the best way.

Alternatively, you might try replaying the question-answer sequence regarding
RTC at install time.

~$ dpkg -S /sbin/hwclock
util-linux: /sbin/hwclock

Perhaps "dpkg-reconfigure util-linux" might cause the same install-time
question be asked again (presumably along with other questions).

Regards
-- 
Abdullah Ramazanoğlu

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

#195942

On Sun, 20 May 2018 22:42:24 +0300 Abdullah Ramazanoğlu said:
 
> Alternatively, you might try replaying the question-answer sequence regarding
> RTC at install time.
> 
> ~$ dpkg -S /sbin/hwclock
> util-linux: /sbin/hwclock
> 
> Perhaps "dpkg-reconfigure util-linux" might cause the same install-time
> question be asked again (presumably along with other questions).
> 
> Regards

Sorry, "debconf-show util-linux" shows nothing, which suggests there's no dpkg
config settings for util-linux. Whether to set the hwclock to UTC or localtime
should have been asked in installing some other package.

Anyway, it was a miss as an alternative way, the main solution being you
initial proposition of "hwclock --localtime"

I would suggest renaming /etc/adjtime (if it exists) so that you can compare
the difference after the change.

-- 
Abdullah Ramazanoğlu

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

#195947

On Sun, 20 May 2018 22:42:24 +0300 Abdullah Ramazanoğlu
<ar018@yahoo.com> wrote:

> On Sun, 20 May 2018 12:10:01 -0700 Patrick Bartek said:
> 
> > On Sat, 19 May 2018 03:52:27 +0300 Abdullah Ramazanoğlu
> > <ar018@yahoo.com> wrote:
> > 
> > > On Fri, 18 May 2018 17:13:07 -0700 Patrick Bartek said:
> > >   
> > > > I could use hwclock --set --date=<yadda yadda> with the
> > > > --localtime option, etc., to correct this but is there an
> > > > easier way?  
> > > 
> > > # dpkg-reconfigure tzdata
> > > 
> > > should do it, I think.  
> > 
> > tzdata sets the local time zone. Mine is correctly set  The
> > problem is the system "thinks" the hardware clock is set to UTC when
> > It's really set to local time. So, the time shown for my local time
> > zone is incorrect.
> > 
> > Anyway, thanks for your suggestion.
> 
> You are welcome. :)
> 
> So, your original idea of using "hwclock --set --date --localtime"
> seems to be the best way.

Simpliest fix.

> Alternatively, you might try replaying the question-answer sequence
> regarding RTC at install time.

Considered this, but just using hwclock was easier.

> ~$ dpkg -S /sbin/hwclock
> util-linux: /sbin/hwclock
> 
> Perhaps "dpkg-reconfigure util-linux" might cause the same
> install-time question be asked again (presumably along with other
> questions).

Thanks

B

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

#195890

On Fri 18 May 2018 at 17:13:07 (-0700), Patrick Bartek wrote:
> Okay, it's my fault: I admit it. During the Base Only, Terminal-only
> install of Stretch, I clicked UTC instead of Local for the hardware
> clock time. Honestly, I thought the clock was set to UTC. Haven't
> installed any other OS on this system since Wheezy 5 years ago. So, now
> system time on Stretch is 7 hours earlier than it should be --
> difference between my time zone and Greenwich.

You could reboot and set the hardware clock in the CMOS/BIOS
to UTC time (coming up to 02:00 Saturday as I send this).

Cheers,
David.

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

#195937

On Fri, 18 May 2018 20:59:25 -0500 David Wright
<deblis@lionunicorn.co.uk> wrote:

> On Fri 18 May 2018 at 17:13:07 (-0700), Patrick Bartek wrote:
> > Okay, it's my fault: I admit it. During the Base Only, Terminal-only
> > install of Stretch, I clicked UTC instead of Local for the hardware
> > clock time. Honestly, I thought the clock was set to UTC. Haven't
> > installed any other OS on this system since Wheezy 5 years ago. So,
> > now system time on Stretch is 7 hours earlier than it should be --
> > difference between my time zone and Greenwich.
> 
> You could reboot and set the hardware clock in the CMOS/BIOS
> to UTC time (coming up to 02:00 Saturday as I send this).

Unfortunately, I have other OSes on this system and they are configured
for the hardware clock set to local time. I need to keep it that way.

Thanks, anyway.

B

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

#195944

Patrick Bartek wrote:
>On Fri, 18 May 2018 20:59:25 -0500 David Wright
><deblis@lionunicorn.co.uk> wrote:
>
>> On Fri 18 May 2018 at 17:13:07 (-0700), Patrick Bartek wrote:
>> > Okay, it's my fault: I admit it. During the Base Only, Terminal-only
>> > install of Stretch, I clicked UTC instead of Local for the hardware
>> > clock time. Honestly, I thought the clock was set to UTC. Haven't
>> > installed any other OS on this system since Wheezy 5 years ago. So,
>> > now system time on Stretch is 7 hours earlier than it should be --
>> > difference between my time zone and Greenwich.
>> 
>> You could reboot and set the hardware clock in the CMOS/BIOS
>> to UTC time (coming up to 02:00 Saturday as I send this).
>
>Unfortunately, I have other OSes on this system and they are configured
>for the hardware clock set to local time. I need to keep it that way.
>
>Thanks, anyway.

The code in the Debian installer that deals with this [1] is:

---------------------------------------
# Update target system configuration for utc/localtime selection
utcfile=/target/etc/default/rcS

db_get clock-setup/utc
if [ "$RET" = true ]; then
        if [ -e $utcfile ]; then
                sed -i -e 's:^UTC="no":UTC="yes":' -e 's:^UTC=no:UTC=yes:' $utcfile
        fi
        if [ -e /target/etc/adjtime ]; then
                sed -i -e 's:^LOCAL$:UTC:' /target/etc/adjtime
        fi
        OPT="--utc"
else
        if [ -e $utcfile ]; then
                sed -i -e 's:^UTC="yes":UTC="no":' -e 's:^UTC=yes:UTC=no:' $utcfile
        fi
        if [ -e /target/etc/adjtime ]; then
                sed -i -e 's:^UTC$:LOCAL:' /target/etc/adjtime
        fi
        OPT="--localtime"
fi
---------------------------------------

If you're using systemd, then /etc/default/rcS is not likely to do
much. However, you may want to check in /etc/adjtime. My machine has
the following:

0.000000 1521991744 0.000000
1521991744
UTC

If yours is saying "UTC" there, then try "LOCAL" instead.

HTH!

[1] https://salsa.debian.org/installer-team/clock-setup/blob/master/finish-install.d/10clock-setup#L118

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

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

#195945

On Sun, 20 May 2018 21:59:08 +0100 Steve McIntyre said:

> The code in the Debian installer that deals with this [1] is:

I have been wondering where this is set during installation. Thanks for the
pointer.

> If you're using systemd, then /etc/default/rcS is not likely to do
> much. However, you may want to check in /etc/adjtime. My machine has
> the following:
> 
> 0.000000 1521991744 0.000000
> 1521991744
> UTC
> 
> If yours is saying "UTC" there, then try "LOCAL" instead.
> 
> HTH!
> 
> [1]
> https://salsa.debian.org/installer-team/clock-setup/blob/master/finish-install.d/10clock-setup#L118

According to hwclock(8);

"A third method is to delete the /etc/adjtime file. Hwclock will then default
to using the UTC timescale for the Hardware Clock. If the Hardware Clock is
ticking local time it will need to be defined in the file. This can be done by
calling hwclock --localtime --adjust; when the file is not present this command
will not actually adjust the Clock, but it will create the file with local time
configured, and a drift factor of zero."

Therefore, if /etc/adjtime is missing (as in my system) that means hardware
clock is set to UTC with zero drift factor. With drift adjusting left to NTP,
there should be no need to set drift factor in /etc/adjtime, leaving "LOCAL"
setting the only plausible reason for it to exist.

BTW --adjust seems to record a drift ratio, so --set might be more appropriate
if drift ratio setting is not wanted. Better to test both options separately
(with a missing /etc/adjtime as a starting point) and see the resulting adjtime
(according to "The Adjtime File" explanation, first field in the first line is
the drift ratio).

In "The Adjust Function" explanation it says:
"Suppose you start with no adjtime file. You issue a hwclock --set command to
set the Hardware Clock to the true current time. hwclock creates the adjtime
file and records in it the current time as the last time the clock was
calibrated."

As for your setup, according to the same man page, your drift rate is zero
(default) and hw clock set to UTC (default), so you could have
removed /etc/adjtime (i.e. rename) just as well, with the same end result.

Regards
-- 
Abdullah Ramazanoğlu

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

#195960

On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:
> > > Haven't
> > > installed any other OS on this system since Wheezy 5 years ago.

Oh, good, then you can simply set the hardware cl--

> Unfortunately, I have other OSes on this system and they are configured
> for the hardware clock set to local time. I need to keep it that way.

Um... OK.  This sudden reversal is confusing to me, but if you've got
it dual-booting between Windows and Linux, then setting the HW clock to
local time may be your simplest option.

In past versions of Debian, this was done by editing the /etc/default/rcS
file.  But that's not true in stretch.

If I'm reading the man pages and the /etc/init.d/* scripts correctly
(as you said you're using sysv-rc rather than systemd), it looks like
the setting for HW clock to UTC or local is in the /etc/adjtime file
now.  There's no separate man page for it.  The documentation for
/etc/adjtime appears to be in the hwclock(8) man page, under the section
header "The Adjtime File".

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

#195966

On Mon, 21 May 2018 09:03:47 -0400 Greg Wooledge <wooledg@eeg.ccf.org>
wrote:

> On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:
> > > > Haven't
> > > > installed any other OS on this system since Wheezy 5 years ago.
> 
> Oh, good, then you can simply set the hardware cl--

I did so.  And everything is fixed as far as I can tell. But had to
reboot Stretch install a couple times before it took. Although, I'm
thinking now I should just reinstall. It's still only a Base
Terminal only system so far. I've yet to flesh it out.  So, no great
loss.

> > Unfortunately, I have other OSes on this system and they are
> > configured for the hardware clock set to local time. I need to keep
> > it that way.
> 
> Um... OK.  This sudden reversal is confusing to me, but if you've got
> it dual-booting between Windows and Linux, then setting the HW clock
> to local time may be your simplest option.

Sorry for the confusion.  I guess my initial post wasn't detailed
enough.

> In past versions of Debian, this was done by editing
> the /etc/default/rcS file.  But that's not true in stretch.

I looked into that as well since I converted Stretch init to sysvinit 

> If I'm reading the man pages and the /etc/init.d/* scripts correctly
> (as you said you're using sysv-rc rather than systemd), it looks like
> the setting for HW clock to UTC or local is in the /etc/adjtime file
> now.  There's no separate man page for it.  The documentation for
> /etc/adjtime appears to be in the hwclock(8) man page, under the
> section header "The Adjtime File".

Read that, too.  And tried changing UTC to LOCAL. No effect even after a
reboot.  Later discovered that /etc/adjtime is only accessed when the
hardware clock is reset.  FWIW, if that file doesn't exist, the default
is UTC.

Thanks for your input.

B

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

#195961

On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:
>Unfortunately, I have other OSes on this system and they are configured
>for the hardware clock set to local time. I need to keep it that way.

For what it's worth, you'll have less long term pain if you also 
configure those to use UTC. Lots of hilarity can ensue when multiple OSs 
decide they need to reset the local time for DST changes...

It's good that MS did eventually figure this out, and provide a 
mechanism to specify that the HW clock is UTC.

Mike Stone

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

#195963

Michael Stone composed on 2018-05-21 09:10 (UTC-0400):

> On Sun, May 20, 2018 at 12:15:05PM -0700, Patrick Bartek wrote:

>>Unfortunately, I have other OSes on this system and they are configured
>>for the hardware clock set to local time. I need to keep it that way.

> For what it's worth, you'll have less long term pain if you also 
> configure those to use UTC. Lots of hilarity can ensue when multiple OSs 
> decide they need to reset the local time for DST changes...

> It's good that MS did eventually figure this out, and provide a 
> mechanism to specify that the HW clock is UTC.

OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and UTC
isn't fun, especially with one or more that can't not, which is what I have with
a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
option. So I keep most on LOCAL, and reboot those that would otherwise be online
as close as I can following each change hour. Those with Windows installed I
configure to not mess with the hardware clock at change times, leaving Linux to
do the deed.

Last fresh installation that got time out of sync with hardware clock was fixed
simply with a change of /etc/adjtime from UTC to LOCAL followed by reboot.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#195964

On Mon, May 21, 2018 at 09:55:42AM -0400, Felix Miata wrote:
>OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and UTC
>isn't fun, especially with one or more that can't not, which is what I have with
>a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
>option. 

I'm afraid I don't understand how things like old standalone boxes 
impact what makes sense going forward. You do understand that there's no 
relationship between the RTC clock and the displayed time? (That is, you 
can set the RTC to UTC and still interact with the system in local 
time.)

Mike Stone

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

#195982

Michael Stone composed on 2018-05-21 10:05 (UTC-0400):

> On Mon, May 21, 2018 at 09:55:42AM -0400, Felix Miata wrote:

>>OS/2 and DOS AFAICT never got that option. A LAN that is a mix of LOCAL and UTC
>>isn't fun, especially with one or more that can't not, which is what I have with
>>a Linux STB providing no LOCAL option and multiple OS/2's providing no UTC
>>option. 

> I'm afraid I don't understand how things like old standalone boxes 
> impact what makes sense going forward. You do understand that there's no 
> relationship between the RTC clock and the displayed time? (That is, you 
> can set the RTC to UTC and still interact with the system in local 
> time.)

Typically, I record on a STB that has no support for /etc/adjtime or
/etc/localtime and see via FTP login the new recording's timestamp is tomorrow
until I wait several hours, and then see it was "recorded" hours after the
program guide and my clock said it aired. I live in today, not tomorrow, and
have no interest in clock time outside an hour or two's drive from home.
Different timestamps across the LAN interfere with evaluation which files of
same name are the newer when choosing, copying, backing up or restoring.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web