Re: Removing "CMOS clock set to UTC" question
- Reply: Matthew Seaman : "Re: Removing "CMOS clock set to UTC" question"
- In reply to: Mark Delany: "Re: Removing "CMOS clock set to UTC" question"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 12 Jun 2024 23:26:41 UTC
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.