On Fri, Apr 27, 2012 at 1:11 AM, Tim Darby <t+df...@timdarby.net> wrote: > I thought this was a bug too and filed my own bug report on it, until it > dawned on me that the intent of the installer is to set the system to UTC > time instead of local time.
No, that's not correct. Look, if the system clock is set to local time, then when presenting the date/time externally, as in the date command, it doesn't need to do the timezone adjustment, because it was already done when the system clock was set. If the system clock is set to UTC, then the time needs to be adjusted for the timezone every time it is presented externally. When /etc/wall_cmos_clock is present, the system behaves as if the system clock is set to local time. You said this yourself in your bug report and you were right. How do I know this is true? Because when I installed the system, I answered 'yes' to the question "Is this machine's CMOS clock set to UTC?". Because of the installer bug, it created /etc/wall_cmos_clock, and the 'date' command displayed a date/time 4 hours in the future. I'm in the EDT timezone, which is UTC-4. So clearly the system was treating the clock as if it were set to local time (it was not adjusting for my timezone, because it thought that had been done due to /etc/wall_cmos_clock being present incorrectly, but the clock was set to UTC time and so it presented me with unadjusted UTC as EDT). And think about this: if the intent of the installer, and thus the developers, was to force the use of UTC, why is there logic in the system to detect the presence of /etc/wall_cmos_clock and treat the clock as local time? I think you had it right the first time, when you entered the bug report, and are confusing yourself now. The bug in the installer should be fixed, so that this system behaves correctly and consistently with the question being asked, and allows the user to choose whether he wants UTC or local time, just like Linux and the other BSDs. This is important, because DragonFly might be installed in a dual-boot setup with Windows, which expects local time in the cmos clock by default (Windows *can* be convinced to use UTC if you edit the registry correctly, but only Windows 7 does this reliably; there are bugs in the UTC support for earlier versions) and so DragonFly needs to handle a local time cmos clock correctly, for people either not running Windows 7 or are disinclined to switch Windows 7 to UTC. /Don In order to make this friendlier to new users, > I suggest two questions in the installer: > > - Do you want UTC time or local time? > - Is this machine's CMOS clock set to UTC? > > Tim > > > > On Thu, Apr 26, 2012 at 9:24 PM, Justin Sherrill <jus...@shiningsilence.com> > wrote: >> >> On Thu, Apr 26, 2012 at 11:41 PM, Donald Allen <donaldcal...@gmail.com> >> wrote: >> > I've installed Dragonfly 3.0.2 on an x86_64 box side-by-side with Arch >> > Linux. Arch is set up for UTC time, America/New_York timezone. When I >> > installed Dragonfly, I selected 'Yes' in response to the question "Is >> > this machine's CMOS clock set to UTC?". Nonetheless, when Dragonfly >> > came up, the time was 4 hours later than it should have been. After a >> > bunch of detective work, I found that the presence of the file >> > /etc/wall_cmos_clock indicates that the hardware clock is set to local >> > time and that it was present. I removed it and the time became correct >> > after a reboot. >> >> I bet the wall_cmos_clock file is present on the install CD and is >> being copied over by cpdup independently. >> >> In any case, the long term answer (separate from fixing the >> installer's behavior) is to set: >> >> dntpd_enable="YES" >> >> in rc.conf to make sure time remains accurate. > >