Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jun 2024 19:26:41 -0400
From:      Ed Maste <emaste@freebsd.org>
To:        Mark Delany <x9k@charlie.emu.st>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: Removing "CMOS clock set to UTC" question
Message-ID:  <CAPyFy2DBYEKCbuK_vfXeZYu4qnB1mTCe0Y3Y2GNmcJEe3fMQ-w@mail.gmail.com>
In-Reply-To: <0.2.0-final-1718212027.814-0x75c1f0@qmda.emu.st>
References:  <CAPyFy2Bo8Mn=Y9g3ePwMN=YOivgTryGpHC4=qzi%2BnJX3c2h68A@mail.gmail.com> <0.2.0-final-1718212027.814-0x75c1f0@qmda.emu.st>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Jun 2024 at 13:07, Mark Delany <x9k@charlie.emu.st> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2DBYEKCbuK_vfXeZYu4qnB1mTCe0Y3Y2GNmcJEe3fMQ-w>