Re: Removing "CMOS clock set to UTC" question

Ed Maste wrote in
 <CAPyFy2DwXpM2K8-1C3Us-2YAw94EQKC1i9RFyuOpyZDXK1A82A@mail.gmail.com>:
 |On Thu, 13 Jun 2024 at 09:50, Rodney W. Grimes
 |<freebsd-rwg@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)