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

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

differences between hwclock <-> date due to time zone issues? ...

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

Contents

  differences between hwclock <-> date due to time zone issues? ... Albretch Mueller <lbrtchx@gmail.com> - 2023-03-23 22:50 +0100
    Re: differences between hwclock <-> date due to time zone issues? ... Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-23 23:10 +0100
    Re: differences between hwclock <-> date due to time zone issues? ... Cindy Sue Causey <butterflybytes@gmail.com> - 2023-03-23 23:10 +0100
      Re: differences between hwclock <-> date due to time zone issues? ... Cindy Sue Causey <butterflybytes@gmail.com> - 2023-03-23 23:30 +0100
    Re: differences between hwclock <-> date due to time zone issues? ... David Wright <deblis@lionunicorn.co.uk> - 2023-03-23 23:50 +0100
    Re: differences between hwclock <-> date due to time zone issues? ... Andy Smith <andy@strugglers.net> - 2023-03-24 15:50 +0100
      Re: differences between hwclock <-> date due to time zone issues? ... Albretch Mueller <lbrtchx@gmail.com> - 2023-03-24 18:20 +0100
        Re: differences between hwclock <-> date due to time zone issues? ... Greg Wooledge <greg@wooledge.org> - 2023-03-24 22:50 +0100
          Re: differences between hwclock <-> date due to time zone issues? ... Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-24 23:00 +0100
            Re: differences between hwclock <-> date due to time zone issues? ... Greg Wooledge <greg@wooledge.org> - 2023-03-24 23:10 +0100
              Re: differences between hwclock <-> date due to time zone issues? ... Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-25 00:20 +0100
                Re: differences between hwclock <-> date due to time zone issues? ... Albretch Mueller <lbrtchx@gmail.com> - 2023-03-25 01:10 +0100
                  Re: differences between hwclock <-> date due to time zone issues? ... Max Nikulin <manikulin@gmail.com> - 2023-03-25 04:20 +0100
                    Re: differences between hwclock <-> date due to time zone issues? ... Albretch Mueller <lbrtchx@gmail.com> - 2023-03-25 04:50 +0100
                      Re: differences between hwclock <-> date due to time zone issues? ... Max Nikulin <manikulin@gmail.com> - 2023-03-25 06:00 +0100
                      Re: differences between hwclock <-> date due to time zone issues? ... Max Nikulin <manikulin@gmail.com> - 2023-03-25 09:00 +0100
                Re: differences between hwclock <-> date due to time zone issues? ... David Wright <deblis@lionunicorn.co.uk> - 2023-03-25 05:30 +0100
        Re: differences between hwclock <-> date due to time zone issues? ... David Wright <deblis@lionunicorn.co.uk> - 2023-03-25 05:30 +0100
          Re: differences between hwclock <-> date due to time zone issues? ... Felix Miata <mrmazda@earthlink.net> - 2023-03-25 05:50 +0100

#256312 — differences between hwclock <-> date due to time zone issues? ...

 I am using this (yes, visually cr@ppy ;-)) code snippet to set back
the time 5 hours. hwclock tells me it worked fine but the terminal
windows opened before and after running hwclock still give me the
"old" time setting?

_HRS_PM=-5

###
# https://stackoverflow.com/questions/1092631/get-current-time-in-seconds-since-the-epoch-on-linux-bash
_DTS=$(date +%s)
echo "// __     \$_DTS: |${_DTS}|";
_DTF=$(date --date @${_DTS})
echo "// __     \$_DTF: |${_DTF}|";

_NEW_DTS=$((_DTS+3600*_HRS_PM))
echo "// __ \$_NEW_DTS: |${_NEW_DTS}|";

# Convert the number of seconds back to date
_NEW_DTF=$(date --date @${_NEW_DTS})
echo "// __ \$_NEW_DTF: |${_NEW_DTF}|";

which hwclock

sudo hwclock --show
sudo hwclock --debug --set --date "${_NEW_DTF}"
sudo hwclock --show

date

// __     $_DTS: |1679606975|
// __     $_DTF: |Thu 23 Mar 2023 09:29:35 PM UTC|
// __ $_NEW_DTS: |1679588975|
// __ $_NEW_DTF: |Thu 23 Mar 2023 04:29:35 PM UTC|
hwclock from util-linux 2.36.1
Thu 23 Mar 2023 09:29:35 PM UTC
$ sudo hwclock --show
2023-03-23 16:30:23.685781+00:00
$ date
Thu 23 Mar 2023 09:31:40 PM UTC

[toc] | [next] | [standalone]

#256313

>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?

The hardware clock is an "external" device which the Linux kernel
typically uses in very limited ways:
1- it reads it at boot to figure out what is the current time to
   initialize the system's own time.
2- it adjusts it every once in a while when the system's time is
   presumed to be more precise (because it's using NTP).

If you want to change the system's time, then change the system's time,
not the hardware clock.

To change the system's time, use `date` (see `man date` for the format
of its arguments).

But changing the system's time is very rarely a good idea.

If you want to change the time based on timezone issues, then change the
*timezone* rather than the time this way your running applications won't
be subjected to time travel, which tends to cause all kinds of odd
behaviors because suddenly the timer that was supposed to fire after
a handful of seconds suddenly waits 5h, or the timeout that should only
fire when there's really no answer after 2min fires right away because
it thinks 5h have passed.  Oh, and connections on the internet may fail
when your machine's time is to too far out of sync (and 5h *is* far),
since some authentication algorithms rely on time constraints.

Note that the timezone is not a system-wide setting.  Every process can
use its own timezone, e.g. by setting the `TZ` environment variable.
Try for example `TZ=UTC date` and then `TZ=Pacific/Samoa date`.
Browse /usr/share/zoneinfo/ to see the list of timezones your system
knows about.


        Stefan

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

#256314

On 3/23/23, Albretch Mueller <lbrtchx@gmail.com> wrote:
>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?
>
> _HRS_PM=-5
>
> ###
> #
> https://stackoverflow.com/questions/1092631/get-current-time-in-seconds-since-the-epoch-on-linux-bash
> _DTS=$(date +%s)
> echo "// __     \$_DTS: |${_DTS}|";
> _DTF=$(date --date @${_DTS})
> echo "// __     \$_DTF: |${_DTF}|";
>
> _NEW_DTS=$((_DTS+3600*_HRS_PM))
> echo "// __ \$_NEW_DTS: |${_NEW_DTS}|";
>
> # Convert the number of seconds back to date
> _NEW_DTF=$(date --date @${_NEW_DTS})
> echo "// __ \$_NEW_DTF: |${_NEW_DTF}|";
>
> which hwclock
>
> sudo hwclock --show
> sudo hwclock --debug --set --date "${_NEW_DTF}"
> sudo hwclock --show
>
> date
>
> // __     $_DTS: |1679606975|
> // __     $_DTF: |Thu 23 Mar 2023 09:29:35 PM UTC|
> // __ $_NEW_DTS: |1679588975|
> // __ $_NEW_DTF: |Thu 23 Mar 2023 04:29:35 PM UTC|
> hwclock from util-linux 2.36.1
> Thu 23 Mar 2023 09:29:35 PM UTC
> $ sudo hwclock --show
> 2023-03-23 16:30:23.685781+00:00
> $ date
> Thu 23 Mar 2023 09:31:40 PM UTC


I left all the above because I didn't know where to safely snip. I
just battled this topic a couple months ago but can't remember which
operating system. It was fixed INSTANTLY by creating /etc/adjtime (if
it doesn't already exist) then entering the following:

0.0 0 0.0

0
UTC

Once saved, it takes just a few seconds then, BAM, there it is!
Everything matches.. IF the hardware clock is set to universal time.

Knowing to do that comes from an uncountable number of debootstrap'ed
Debian releases. The step can be found here under the "D.3.4.3.
Setting Timezone" heading:

https://www.debian.org/releases/wheezy/amd64/apds03.html.en#idp7856176

If your hardware clock is not UTC, I've never gone there so I don't
know. My CHOICE is UTC because a tip many years ago advised that doing
so helps our computers stay in sync more seamlessly with the rest of
the World. Whether that's true or not, I don't know that, either, but
going this route sure has taken the pain out of the local time keeping
end of all of this *for me*. :)

Cindy :)

Notable: If /etc/adjtime exists and has data that is anything other
than the 0.0s in there, my experience has been that occurs when I
don't have my hardware clock set up properly. When I go the UTC/0.0
route, my file never changes. That data, those numbers, is/are the
computer doing its own thing trying to keep things aligned based on
.e.g our correct and incorrect date commands issued via programs like
hwclock.
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

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

#256315

On 3/23/23, Cindy Sue Causey <butterflybytes@gmail.com> wrote:
> On 3/23/23, Albretch Mueller <lbrtchx@gmail.com> wrote:
>>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
>> the time 5 hours. hwclock tells me it worked fine but the terminal
>> windows opened before and after running hwclock still give me the
>> "old" time setting?
>>
>> _HRS_PM=-5
>>
< snipped for brevity >
>
> just battled this topic a couple months ago but can't remember which
> operating system. It was fixed INSTANTLY by creating /etc/adjtime (if
> it doesn't already exist) then entering the following:
>
> 0.0 0 0.0
> 0
> UTC
>
> Once saved, it takes just a few seconds then, BAM, there it is!
> Everything matches.. IF the hardware clock is set to universal time.
>
< snipped for brevity >

Not quite. I forgot to say you also need to issue the following
command afterward:

# dpkg-reconfigure tzdata

That's where you get to pick your timezone which is the other thing I
forgot to mention. I saw Stefan referenced the topic so I wasn't going
to create any more noise until I realized I'd left off tzdata. The
good news there is the Debian debootstrap link covers that, too:

https://www.debian.org/releases/wheezy/amd64/apds03.html.en#idp7856176

Next time I'll try to remember to fully read my own offered resource
before hitting "Send".

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

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

#256316

On Thu 23 Mar 2023 at 21:41:40 (+0000), Albretch Mueller wrote:
>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?

You're in my time zone, aren't you, so your hardware clock (UTC)
should be five hours ahead of the system clock (CDT). What are
the two times on your system?

  # hwclock --verbose
  hwclock from util-linux 2.36.1
  System Time: 1679611469.019755
  Trying to open: /dev/rtc0
  Using the rtc interface to the clock.
  Last drift adjustment done at 1650159782 seconds after 1969
  Last calibration done at 1650159782 seconds after 1969
  Hardware clock is on UTC time
  Assuming hardware clock is kept in UTC time.
  Waiting for clock tick...
  ...got clock tick
→ Time read from Hardware Clock: 2023/03/23 22:44:30
  Hw clock time : 2023/03/23 22:44:30 = 1679611470 seconds since 1969
  Time since last adjustment is 29451688 seconds
  Calculated Hardware Clock drift is 0.000000 seconds
→ 2023-03-23 17:44:28.998946-05:00
  # 

Cheers,
David.

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

#256323

Hello,

On Thu, Mar 23, 2023 at 09:41:40PM +0000, Albretch Mueller wrote:
>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?

As already pointed out, the hardware clock is used in very limited
ways and is not the same thing as the system clock, so your result
is as expected.

What are you actually trying to do?

What "time zone issues" do you refer to?

It is very rare to need to modify the hardware clock. Typically it's
only done at shutdown time by the base OS to save the system clock
to the hardware clock ready for next boot, as the system clock is
assumed to be more accurate.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#256329

On 3/24/23, Andy Smith <andy@strugglers.net> wrote:
> As already pointed out, the hardware clock is used in very limited
> ways and is not the same thing as the system clock, so your result
> is as expected.
> What are you actually trying to do?
>
> What "time zone issues" do you refer to?

 I should have pointed out that I always go into exposed mode (use the
Internet) with a live DVD. My laptop was always 6 hours ahead and now
that they changed to summer time, it is 5 hours ahead.
 I used logs which names a time a la:

_DT=$(date +%Y%m%d%H%M%S)
_BN=$(basename "${_SDIR}")
_LOG_FL="${_BN}_${_DT}.log"
...
 If anything, timing is one of the aspects of reality which should be
coordinated.
 lbrtchx

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

#256336

On Fri, Mar 24, 2023 at 05:13:31PM +0000, Albretch Mueller wrote:
>  I should have pointed out that I always go into exposed mode (use the
> Internet) with a live DVD. My laptop was always 6 hours ahead and now
> that they changed to summer time, it is 5 hours ahead.

So, you have at least two operating systems that you boot on this
computer: one (Debian 11????) installed to fixed disk, and one (Debian
Live 11????) on removable media.

If your two operating systems disagree over whether the HW clock should
be set to UTC or to local time, you will get these issues.

Most people who experience these issues are dual-booting Linux and
Windows -- again, two different operating systems, which may have two
different ideas of how to set the HW clock.  Your case is the same,
just with two different Linuxes.

The solution is to decide how you want all of your operating systems to
read/set the HW clock (UTC or local), and to make sure they both implement
your chosen policy.

Since one of your operating systems may be impossible to configure, that
one's treatment of the HW clock may dictate the policy choice you need
to make for the other OS.

If your policy choice ends up being "set HW clock to local", then you
also have to make sure the correct time zone is set on each operating
system, each time it boots.  I have no idea how one does that on Debian
Live, since I've never used Debian Live.  So, I can hope for your sake
that Debian Live uses a UTC HW clock.

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

#256338

> If your policy choice ends up being "set HW clock to local", then you
> also have to make sure the correct time zone is set on each operating
> system, each time it boots.  I have no idea how one does that on Debian
> Live, since I've never used Debian Live.  So, I can hope for your sake
> that Debian Live uses a UTC HW clock.

You may also circumvent the problem by making sure your "online" OS is
configured to set its time via NTP once it gets access to the Internet,
this way, any problem with the hwclock will only impact the "boot".

Many routers face a similar problem because they don't have any hwclock,
so at the beginning of the boot they basically don't know what time it
is (it's arbitrarily initialized to some "dummy" value like 01-Jan-1970
or to some timestamp saved at some point in the past), and they only get
a valid time after they can connect to an NTP server.


        Stefan

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

#256341

On Fri, Mar 24, 2023 at 05:51:30PM -0400, Stefan Monnier wrote:
> > If your policy choice ends up being "set HW clock to local", then you
> > also have to make sure the correct time zone is set on each operating
> > system, each time it boots.  I have no idea how one does that on Debian
> > Live, since I've never used Debian Live.  So, I can hope for your sake
> > that Debian Live uses a UTC HW clock.
> 
> You may also circumvent the problem by making sure your "online" OS is
> configured to set its time via NTP once it gets access to the Internet,
> this way, any problem with the hwclock will only impact the "boot".

That works great for the Live OS, but not for the fixed-disk OS.  If
the Live OS sets the HW clock to local upon shutdown, but the fixed-disk
OS expects the HW clock to be UTC, then the fixed-disk OS is wrong
every time it boots after the Live OS.

... unless the Live OS can be configured to shut down WITHOUT touching
the HW clock at all.  (Can Debian Live be configured that way?  I have
no idea.)

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

#256343

> That works great for the Live OS, but not for the fixed-disk OS.  If
> the Live OS sets the HW clock to local upon shutdown, but the fixed-disk
> OS expects the HW clock to be UTC, then the fixed-disk OS is wrong
> every time it boots after the Live OS.

AFAIK the Linux kernel is pretty careful not to change the *hour* of the
hwclock: when using NTP, it will tweak the seconds to keep the hwclock
in sync with the rest of the world, but leave the hours alone, so as to
preserve the timezone in use, regardless if it's the right one (UTC) or
something else.

I assume GNU/Linux distributions like Debian are similarly careful,
since dual booting with a Windows install that doesn't use UTC for the
hwclock was a very common use case at least some years ago.


        Stefan

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

#256345

 I am using right now a DELL laptop which had Windows 11 installed but
started to give me sh!t which I totally ignored and started to use my
good old friend Debian in order to "keep moving".
 By the way, after a while as if for a magical reason the hw time
changed and now it is showing to me the same time I can see on
 https://www.timeanddate.com/
 for my time zone. Devices I use seems to develop a mind of their own ;-)
 lbrtchx

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

#256350

On 25/03/2023 07:07, Albretch Mueller wrote:
>   I am using right now a DELL laptop which had Windows 11 installed but

I expect that the following should work smoothly enough:
- Hardware clock is in UTC
- Both Debian and Windows installed on the hard drive are configured to 
your local time zone (with installed updates related to tzdata) and 
aware that hardware clock is in in UTC
- When you boot a live image, you run a command like

     timedatectl set-timezone America/Chicago

   You might need to update tzdata package if you reside in a time zone 
with time offset rules have changed later than the live image was prepared.

What are your issues with such workflow?

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

#256351

On 3/25/23, Max Nikulin <manikulin@gmail.com> wrote:
> - Both Debian and Windows installed on the hard drive ...
 Thank you for the steps and the logical elucidations that may
certainly help someone else, but I can't do that "because" all
electronic devices which I use are being kept.
 You can't physically alter a DVD[+|-]R once it is burned ...
 lbrtchx

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

#256357

On 25/03/2023 10:39, Albretch Mueller wrote:
> On 3/25/23, Max Nikulin wrote:
>> - Both Debian and Windows installed on the hard drive ...
>   Thank you for the steps and the logical elucidations that may
> certainly help someone else, but I can't do that "because" all
> electronic devices which I use are being kept.

System clock in UTC and time offset rules from time zone database is a 
way to reduce maintenance burden. E.g. you do not need to learn how to 
synchronize hardware clock and runtime system clock.

>   You can't physically alter a DVD[+|-]R once it is burned ...

Notice that for the case of DVD I suggested

     timedatectl set-timezone America/Chicago

when the system is booted. There may be a UI dialog to configure 
timezone. I have no idea concerning desktop environment on your DVD.

I have never tried if timezone may be configured from DHCP response when 
your computer gets its IP address. Such tricks may eliminate necessity 
to type commands. I assume that a query to a geolocation service to 
guess time zone is not an option for you.

Anyway you need to regularly burn new disks to have latest security 
updates, so tzdata should not be terribly outdated as well.

Finally at least some CD-R and DVD±R formats allows to not close session 
and to add more files later. Perhaps it may be used to customize an 
image to add a script to configure time zone, add some updates, etc.

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

#256359

On 25/03/2023 10:39, Albretch Mueller wrote:
>   You can't physically alter a DVD[+|-]R once it is burned ...

Do you customize images to change preferences, e.g. to make OS aware 
that hardware clock is set to local time? If you do not than OS almost 
certainly assumes that system time is in UTC, so you may experience 
bizarre TLS-related errors. If you do than it is better to set actual 
timezone instead and to get daylight saving time transitions out of the box.

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

#256354

On Fri 24 Mar 2023 at 19:10:49 (-0400), Stefan Monnier wrote:
> > That works great for the Live OS, but not for the fixed-disk OS.  If
> > the Live OS sets the HW clock to local upon shutdown, but the fixed-disk
> > OS expects the HW clock to be UTC, then the fixed-disk OS is wrong
> > every time it boots after the Live OS.
> 
> AFAIK the Linux kernel is pretty careful not to change the *hour* of the
> hwclock: when using NTP, it will tweak the seconds to keep the hwclock
> in sync with the rest of the world, but leave the hours alone, so as to
> preserve the timezone in use, regardless if it's the right one (UTC) or
> something else.

Minutes, rather than hours, I would have thought. After all, there are
some crazy TZs out there, and even crazier daylight savings schemes.

> I assume GNU/Linux distributions like Debian are similarly careful,
> since dual booting with a Windows install that doesn't use UTC for the
> hwclock was a very common use case at least some years ago.

Cheers,
David.

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

#256355

On Fri 24 Mar 2023 at 17:13:31 (+0000), Albretch Mueller wrote:
> On 3/24/23, Andy Smith <andy@strugglers.net> wrote:
> > As already pointed out, the hardware clock is used in very limited
> > ways and is not the same thing as the system clock, so your result
> > is as expected.
> > What are you actually trying to do?
> >
> > What "time zone issues" do you refer to?
> 
>  I should have pointed out that I always go into exposed mode (use the
> Internet) with a live DVD. My laptop was always 6 hours ahead and now
> that they changed to summer time, it is 5 hours ahead.
>  I used logs which names a time a la:
> 
> _DT=$(date +%Y%m%d%H%M%S)
> _BN=$(basename "${_SDIR}")
> _LOG_FL="${_BN}_${_DT}.log"
> ...
>  If anything, timing is one of the aspects of reality which should be
> coordinated.

Hence the existence of UTC since around 1960: Coordinated Universal Time.

But to benefit from it, you also have to coordinate your computers
/and/ their OSes. I can't imagine trying to run a laptop with its RTC
on Local time, because of time zone changes when travelling. I suppose
it's just about possible to manage it on a desktop computer in Arizona.

Like Greg, I've not used Live systems to any extent, and don't know
how they handle setting a time zone.

BTW I've only really trusted reading or setting the RTC by means of
the CMOS screens, and treat it as a one-time only process (upon
acquisition), assuming the coin-cell battery never needs replacing.
(All my computers have begun life running Windows.)

Cheers,
David.

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

#256356

David Wright composed on 2023-03-24 23:20 (UTC-0500):

> BTW I've only really trusted reading or setting the RTC by means of
> the CMOS screens, and treat it as a one-time only process (upon
> acquisition), assuming the coin-cell battery never needs replacing.

Lucky you. I can only dream of going more than 3 months without something needing
its 2032 replaced. Unplugged old Dells devour them.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

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

Felix Miata

[toc] | [prev] | [standalone]

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

csiph-web