Ed Maste wrote in
<CAPyFy2DwXpM2K8-1C3Us-***@mail.gmail.com>:
|On Thu, 13 Jun 2024 at 09:50, Rodney W. Grimes
|<freebsd-***@gndrsh.dnsmgr.net> wrote:
|>
|> You could use this data to present a time based on CMOS with and without
|> the TZ offset and derive the correct wall_cmos_clock value.
|>
|> Please try to make things better, not just less confusing.
|
|Can you please explain how that is making this better?
|
|First, on a brand new install the RTC may be off by several hours or
|days, or may be correct but for a completely wrong timezone, perhaps
|where the machine was manufactured. So then we'd have to fist pick a
|timezone, then ask:
|
|Is the current time
|( ) 10:31
|( ) 15:31
|( ) Something else
|
|If you pick "something else" we need to ask the user for the current
|time, and then still need to ask them whether the RTC should be set to
|UTC or local time.
I feel you have your "expert hat" of decades of programmer
knowledge on.
The thing that is plain is that the questions are too sharply
edged (i had a bad experience with "something similar" in the
network area of a NetBSD 10 install), normal users then stand in
front of a wall and shake their heads.
See for example what the Linux hwclock(8) says (once installed):
LOCAL vs UTC
Keeping the Hardware Clock in a local timescale causes inconsistent
daylight saving time results:
• If Linux is running during a daylight saving time change, the time
written to the Hardware Clock will be adjusted for the change.
• If Linux is NOT running during a daylight saving time change, the
time read from the Hardware Clock will NOT be adjusted for the
change.
The Hardware Clock on an ISA compatible system keeps only a date and
^ scratch ISA
time, it has no concept of timezone nor daylight saving. Therefore, when
hwclock is told that it is in local time, it assumes it is in the
'correct' local time and makes no adjustments to the time read from it.
Linux handles daylight saving time changes transparently only when the
Hardware Clock is kept in the UTC timescale. Doing so is made easy for
system administrators as hwclock uses local time for its output and as
the argument to the --date option.
^ Some insight, some context!!
POSIX systems, like Linux, are designed to have the System Clock operate
in the UTC timescale. The Hardware Clock’s purpose is to initialize the
System Clock, so also keeping it in UTC makes sense.
^ Uh-oh!
Linux does, however, attempt to accommodate the Hardware Clock being in
the local timescale. This is primarily for dual-booting with older
versions of MS Windows. From Windows 7 on, the RealTimeIsUniversal
registry key is supposed to be working properly so that its Hardware
Clock can be kept in UTC.
^ Ah-ha!
Now if you buy something with preinstalled Windows, it is likely
you boot it first. (I *had*, i even had to keep Windows, because
Linux kernels (4.19 and) 5.10 would at times make the Wifi
unusable, it required a boot (not in)to Windows to properly
(re)initialize the thing. (Cries to explain or document
rtw88_pci.disable_aspm=1 then were left unanswered, in addition.)
This means your clock is already set .. no?
But even if not, with an excerpt of the above, plus the time as
read from the clock, a user could be enabled to make a profound
decision (based on "current" context). imho.
Having said that i realize that the (super large) preinstalled
FreeBSD VM qcow2 images i personally use for some years (no on
bare metal currently) just work out of the box, correctly as it
seems.
Thank you.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de