Time problem

[Donald Allen]

On Fri, Apr 27, 2012 at 1:11 AM, Tim Darby <t+dfbsd at 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 <justin at shiningsilence.com>
> wrote:
>>
>> On Thu, Apr 26, 2012 at 11:41 PM, Donald Allen <donaldcallen at 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.
>
>