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. 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. >
