You are not logged in.
Pages: 1
Hello, friends!
I have the following situation in Devuan 2 and Devuan 3:
hwclock --utc
2020-02-29 02:15:50.889268+03:00
hwclock --localtime
2020-02-28 23:16:54.311448+03:00
This is wrong!!!
Must be:
hwclock --utc
2020-02-28 20:15:50.889268+00:00
hwclock --localtime
2020-02-28 23:16:54.311448+03:00
After a reboot, the BIOS sets the time to UTC, which should be localtime.
Please report this issue to the hwclock developers.
Thanks!
Last edited by Eaglet (2020-02-29 20:50:23)
Offline
How is your Devuan box configured? Is it set to UTC or localtime? If you don't know then check the last line in /etc/adjtime
It is recommended to set GNU/Linux systems to UTC, even if dual-booting with Windows. For dual-boot systems you should instead force Windows to use UTC with the RealTimeIsUniversal registry key.
Use this to check your system timezone:
ls -l /etc/localtime
If it's wrong then use
# dpkg-reconfigure tzdata
Brianna Ghey — Rest In Power
Offline
How is your Devuan box configured? Is it set to UTC or localtime? If you don't know then check the last line in /etc/adjtime
It is recommended to set GNU/Linux systems to UTC, even if dual-booting with Windows. For dual-boot systems you should instead force Windows to use UTC with the RealTimeIsUniversal registry key.
Use this to check your system timezone:
ls -l /etc/localtime
If it's wrong then use
# dpkg-reconfigure tzdata
Yes! My tzdata is configured. Issue only with hwclock util. I not use MS Windows systems over 10 years!!!
You are not careful! I repeat!
Must be:
hwclock --utc
2020-02-28 20:15:50.889268+00:00
hwclock --localtime
2020-02-28 23:16:54.311448+03:00
Last edited by Eaglet (2020-02-29 21:00:45)
Offline
Just for fun I checked with my ASCII PC and on my fileserver running Beowulf. On both identical behaviour. I am confused.
Mate displays 11:21.
hwclock --utc
2020-03-01 11:21:00.327413+01:00
hwclock --localtime
2020-03-01 10:21:11.155645+01:00
ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 Sep 25 22:48 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin
I would expect it the other way round. ???
rolfie
Online
rolfie, I got results similar to yours, except I'm the other side of UTC, so mine have '-' instead of '+'. Don't feel bad about being confused. I've been confused by hwclock for years, so I stay away from it. I set it to UTC and use ntp or ntpdate to keep the right time.
Offline
Thanks for confirming, I feel better now since I understand I am not alone. The BIOS is set to Greenwich time, the desktop shows the time what is to expect and complies to my three radio controlled clocks, sync is done via ntp/ntpdate, despite the confusing output everything seems to be working right.
Have a nice Sunday, rolfie
Online
rolfie, fsmithred!
You Trolls! Here, trolls, we're talking about hwclock, not ntp, ntpdate, ntpdate! Write on the topic, and do not clog the discussion with your wet dreams!
Last edited by Eaglet (2020-03-01 13:44:29)
Offline
@Eaglet,
you might want to read man hwclock more carefullly, and then pay special attention to the documentation of the --show option, which clearly states, in so many words:
The time shown is always in local time, even if you keep your Hardware Clock in UTC.
The options --utc and --localtime are for you to tell about time basis of your clock. The program then presents the clock reading in ISO 8601 format local time with respect to that basis.
Offline
@Eaglet,
you might want to read man hwclock more carefullly, and then pay special attention to the documentation of the --show option, which clearly states, in so many words:The time shown is always in local time, even if you keep your Hardware Clock in UTC.
The options --utc and --localtime are for you to tell about time basis of your clock. The program then presents the clock reading in ISO 8601 format local time with respect to that basis.
1. UTC time should end at +00:00, not as it is now +xx:00. Local time should end at +/-xx:00.
2. I did not change the settings in the BIOS, hwclock itself set the time in UTC in the BIOS. This should not be the case, so that changes are made to the system without the user's participation.
3. See about ISO 8601 https://en.wikipedia.org/wiki/ISO_8601#Times
4. The above suggests that one of the developers of hwclock got stoned with marijuana.And you repeat the nonsense of a crazy developer hwclock.
Offline
Stop calling it UTC time. That's not what it is. It's local time.
The very first code block in your first post is correct. The hwclock command is doing exactly what the man page says it does. It's showing you the local time and your local offset from UTC in both cases.
One shows the correct local time because you gave the hwclock accurate information, and the other shows the incorrect local time because you gave the hwclock command incorrect information.
hwclock --utc
2020-02-29 02:15:50.889268+03:00
hwclock --localtime
2020-02-28 23:16:54.311448+03:00
You're welcome to contact the author(s) of hwclock and ask them to change the behavior of the command, but I doubt they'll change it.
Offline
I agree with Eaglet that the way hwclock works is a bit confusing. So I decided to get to the bottom of things on my machine. Here's what I did. I hope it helps...
First, we have to realize that the hardware clock knows nothing about timezone. It holds a date and a time, that's it.
It's up to the user to tell the operating system the correct timezone and whether the hardware clock is set to UTC (recommended for Unix-like OS) or localtime (recommended if you dual boot with Windows).
Before I show you the output of some commands, here are some facts:
- It's currently 15:35 UTC
- I live in Eastern USA, where timezone is EST (UTC-5)
- My local time is 10:35 a.m.
Okay, now for the commands:
$ sudo hwclock --get --debug | grep "Time read" # this command will show exactly what the hardware clock is saying
Time read from Hardware Clock: 2020/03/05 15:35:32
# Hmmm, hardware clock says it's 15:35, so it's obviously set to UTC. Let's make sure my OS knows that...
$ cat /etc/adjtime
0.000000 1583421556 0.000000
1583421556
UTC
# Notice the third line in the output above. That line tells the OS how to interpret the hardware clock. Mine should say UTC, which it does.
$ cat /etc/timezone
America/New_York
# So hardware clock is set to the correct UTC time, OS knows to interpret hardware clock as UTC, and my timezone is correct. Therefore, when "date" or "hwclock" command puts it all together, it should spit out my correct local time:
$ date
Thu Mar 5 10:35:06 EST 2020 # yep, that's the correct local time
$ sudo hwclock # or sudo hwclock --utc
2020-03-05 10:35:09.546002-0500 # yep, that's the correct local time
So as you can see, your OS showing you the correct local time is a complex operation. It requires 3 things: hardware clock being set correctly (to either UTC or local time), your OS knowing whether hardware clock is set to UTC or local time, and your OS knowing your time zone.
Hope that helps.
P.S. The --utc and --localtime flags to hwclock are to tell hwclock which timescale the hardware clock is set to (hwclock assumes UTC, so the --utc flag is redundant). Eaglet, If you your hardware clock is set to UTC you should never use the --localtime flag because it will give you incorrect (and potentially very confusing) results.
Last edited by GNUser (2020-03-05 18:03:01)
Offline
You are not careful! I repeat!
Must be:hwclock --utc
2020-02-28 20:15:50.889268+00:00
That's not correct. The output of the hwclock command is your local time, and what comes after the final + or - is your timezone's offset from UTC. +00:00 would only be correct for users who live in Greenwich
Please go over the steps above in my longer post. If you still have questions after that, let me know and I'll try to help.
Last edited by GNUser (2020-03-05 16:24:23)
Offline
localtime (recommended if you dual boot with Windows)
Use of localtime is never recommended, people who dual-boot with Windows should force Windows to use UTC instead: https://wiki.archlinux.org/index.php/Sy … in_Windows
@OP: sorry for the diversion.
Brianna Ghey — Rest In Power
Offline
I stand corrected, and edited my walk-through to reflect this. Thank you, HoaS.
Last edited by GNUser (2020-03-05 18:04:59)
Offline
Pages: 1