From nobody Wed Jun 12 23:26:41 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 4W01sC2Yl5z5KxrK for ; Wed, 12 Jun 2024 23:26:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W01sC0l2gz4cK9 for ; Wed, 12 Jun 2024 23:26:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f51.google.com with SMTP id ca18e2360f4ac-7eb7c0f9784so14953539f.2 for ; Wed, 12 Jun 2024 16:26:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718234813; x=1718839613; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1jEslg3pcLtkqE10EZahewXrasvIslp/KJZ5ruQQNFc=; b=rdK8kysfBborVzQv7Gol44R4/3yZ34MlqZC41kCEcKochXkZooIQmyPiLK5qTl6uft YNGdJ20HC6iphHhLvjsFPyRcrJiAraby+UzkDvJASgSPq5qe2zZPW0mtiAj86TyD5TrR frVeXyxqcxL1sOJFbRlUkGqSWn135NOzP5DAd0mhfBH2dkb8yTnHJrZbIbcLVsihwhcM hhkG7HuXwTRmDx0IL4ocxyebuF3smv74cck693sLZkVIeJZ6EVmm1L+joEosDn/dWdrB euLOD3sVHyPwB/njCn0+KK/p4GhD6Hvx4NAggmwBgPIlJy3pfAWKz74l8suk85nr9EmT dEMA== X-Gm-Message-State: AOJu0YwIFLD42XPdUStO1ECUFYk7Ynq0VeoQGqZ9wuN9v+QbystHo6Vv 9nkyQc43oWuZVm0S+njNW90Ox14eAyov76KPWRybj2CETAcc1Ye9yD+PHFZ719sge66ByCsYGYl 0AnJ45SYcgvqCEzmhUvkMbE/st0dsaLhx X-Google-Smtp-Source: AGHT+IGVj/hJCOAc7xMqROXIFxiDSFjv57cDn+fC7+ZIFtVofDHoobBoOAPYSRMOqQgtipizhrRgAdCjiluZGzYGpjo= X-Received: by 2002:a05:6602:6419:b0:7eb:85a8:bfdb with SMTP id ca18e2360f4ac-7ebcd190e1cmr361095639f.17.1718234813304; Wed, 12 Jun 2024 16:26:53 -0700 (PDT) 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 References: <0.2.0-final-1718212027.814-0x75c1f0@qmda.emu.st> In-Reply-To: <0.2.0-final-1718212027.814-0x75c1f0@qmda.emu.st> From: Ed Maste Date: Wed, 12 Jun 2024 19:26:41 -0400 Message-ID: Subject: Re: Removing "CMOS clock set to UTC" question To: Mark Delany Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" 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:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4W01sC0l2gz4cK9 On Wed, 12 Jun 2024 at 13:07, Mark Delany wrote: > > On 12Jun24, Ed Maste apparently wrote: > > Our installer asks (via tzsetup): > > > > > Is this machine's CMOS clock set to UTC? If it is set to local time, > > > or you don't know, please choose NO here! > > > > I've heard many reports of new users being confused by this question > > And experienced users too! > > I've been installing FBSD and various other OSes for decades and whenever I see that > question invariable: Thank you for your reply -- the points you raised exactly capture the sort of uncertainty raised by the installer's question and highlight why I'd like to get rid of it. > a) I have no clue as to what the machine's CMOS clock is set to in the first instance Indeed, and the blame for this lies with the question. Whether the machine's clock is currently (at the time of installation) set to UTC is actually not all that interesting. What we really want to know is if the user desires to have UTC in the CMOS clock. > b) I do not want the hassle of stopping the install to gain access to some obscure BIOS > screen that might or might not give me the answer. Indeed, and that information isn't needed anyway. > c) I have no clue as to the implications of answering this question one way or the > other. The answer to this question has one effect. If you answer NO the file /etc/wall_cmos_clock is created, and removed if you answer YES. adjkerntz(8) uses the presence of this file to apply a timezone offset when reading from / writing to the real-time (CMOS) clock. > d) I don't know whether it's a good idea or not to change the CMOS clock to UTC if it's > not the case. Is it? If FreeBSD is the only operating system installed on the machine UTC is preferred but it will work either way. If you want to dual-boot they you probably want local time which is what Windows uses by default. When this functionality was first added to tzsetup it came with a comment: | You can configure your system to assume that the battery-backed CMOS | clock is set to your local legal time rather than Universal or | Greenwich time. When the system boots, the \`adjkerntz' program will | examine your current time, reverse-apply the timezone correction, and | then set the system's UTC time to the corrected value. This approach | is NOT guaranteed to always work; in particular, if you reboot your | system during the transition from or to summer time, the calculation | is sometimes impossible, and wierd things may result. | | For this reason, we recommend that, unless you absolutely positively | must leave your CMOS clock on local time, you set your CMOS clock to GMT. This is decent advice. Use UTC unless you will dual-boot Windows. > e) I don't think I've ever seen a similar question asked by any other OS install. I'm not aware of any other OSes asking this. From what I've seen Windows assumes local time and every other OS assumes UTC. > At the very least the message should indicate what happens if you get the answer > wrong. Does the system fail to install, does the clock run backwards, will my dog stop > barking? What? If you choose UTC and reboot into Windows and don't have a network connection the time in Windows will be wrong. If you choose local time the issue in the comment above can apply.