From nobody Thu Jun 13 17:01:02 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0TFc6wKZz5P0Lf for ; Thu, 13 Jun 2024 17:01:08 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0TFc3P7Tz4XGS; Thu, 13 Jun 2024 17:01:08 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1718298064; x=1718964730; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:mime-version: content-type:content-transfer-encoding:author:from:subject:date:to:cc: resent-author:resent-date:resent-from:resent-sender:resent-to:resent-cc: resent-reply-to:resent-message-id:in-reply-to:references:mime-version: content-type:content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=jLnOk/M7HxDgzJde7pbMEoqFTEvTFPV5UTRvSisqFns=; b=d7HtGtFVmg0FPWWFKWbWg46TPJ2GEv2gV4cPM4JBGusivx9LXcHeEFWZtmwWhLNPRFkLI4If YaOdc48polLxNJXrOOuTMK44El7kMjrQz+MFCQaPqPLinDG9VoTFX20np3xBP9WYHxVJk/WHMq 9/NsKz59/o0tNSslNQCv0+aWpL0F+sR8kwOjC/90s8aVYf50EwgUvNo+HB4rRlPkK7IQ0VQD8s A5syASHQL3k0emUAmhSRNZfb3tv5R4Iv5Do9B6PI/jn+8UQ6bKWbHSYthhEDn8hkoddMfCsfQz uTm0b7/BiuVXSzEHS/cXrTQWbcK6hZH6HvIMSGvV0T2lvNRA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1718298064; x=1718964730; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:openpgp:blahblahblah:mime-version: content-type:content-transfer-encoding:author:from:subject:date:to:cc: resent-author:resent-date:resent-from:resent-sender:resent-to:resent-cc: resent-reply-to:resent-message-id:in-reply-to:references:mime-version: content-type:content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=jLnOk/M7HxDgzJde7pbMEoqFTEvTFPV5UTRvSisqFns=; b=YSOU7gzUoampwbyKFC7r1r7qaUU9BYSrlDzRz5OOxJj0DhqXBHHAuAsZB2A3j8WHY/TPciWl pKu0oDo1OScwBQ== Date: Thu, 13 Jun 2024 19:01:02 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Ed Maste Cc: "Rodney W. Grimes" , Bertrand Petit , freebsd-hackers@freebsd.org Subject: Re: Removing "CMOS clock set to UTC" question Message-ID: <20240613170102.s6BQpmXu@steffen%sdaoden.eu> In-Reply-To: References: <202406131350.45DDobuA044814@gndrsh.dnsmgr.net> User-Agent: s-nail v14.9.24-621-g0d1e55f367 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4W0TFc3P7Tz4XGS Ed Maste wrote in : |On Thu, 13 Jun 2024 at 09:50, Rodney W. Grimes | 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: =E2=80=A2 If Linux is running during a daylight saving time change, = the time written to the Hardware Clock will be adjusted for the change. =E2=80=A2 If Linux is NOT running during a daylight saving time chan= ge, 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, wh= en 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 opera= te in the UTC timescale. The Hardware Clock=E2=80=99s purpose is to initi= alize 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=3D1 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)