Time problem

[Tim Darby]

--14dae9340893e36fef04bea22476
Content-Type: text/plain; charset=ISO-8859-1

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

--14dae9340893e36fef04bea22476
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<font><font face=3D"trebuchet ms,sans-serif">I thought this was a bug too a=
nd 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. =A0In=
 order to make this friendlier to new users, I suggest two questions in the=
 installer:</font></font><div>

<font><font face=3D"trebuchet ms,sans-serif"><br></font></font></div><div><=
font><font face=3D"trebuchet ms,sans-serif">- Do you want UTC time or local=
 time?</font></font></div><div><font><font face=3D"trebuchet ms,sans-serif"=
>-=A0</font></font>Is=A0this machine's CMOS clock set to UTC?=A0<font><=
font face=3D"trebuchet ms,sans-serif"><br clear=3D"all">

</font></font><div><br></div>Tim<br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Apr 2=
6, 2012 at 9:24 PM, Justin Sherrill <span dir=3D"ltr"><<a href=3D"mailto=
:justin at shiningsilence.com" target=3D"_blank">justin at shiningsilence.com</a>=
></span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, Apr 26, 2012 at 11=
:41 PM, Donald Allen <<a href=3D"mailto:donaldcallen at gmail.com">donaldca=
llen at gmail.com</a>> wrote:<br>


> I've installed Dragonfly 3.0.2 on an x86_64 box side-by-side with =
Arch<br>
> Linux. Arch is set up for UTC time, America/New_York timezone. When I<=
br>
> installed Dragonfly, I selected 'Yes' in response to the quest=
ion "Is<br>
> this machine's CMOS clock set to UTC?". Nonetheless, when Dra=
gonfly<br>
> came up, the time was 4 hours later than it should have been. After a<=
br>
> bunch of detective work, I found that the presence of the file<br>
> /etc/wall_cmos_clock indicates that the hardware clock is set to local=
<br>
> time and that it was present. I removed it and the time became correct=
<br>
> after a reboot.<br>
<br>
</div>I bet the wall_cmos_clock file is present on the install CD and is<br=
>
being copied over by cpdup independently.<br>
<br>
In any case, the long term answer (separate from fixing the<br>
installer's behavior) is to set:<br>
<br>
dntpd_enable=3D"YES"<br>
<br>
in rc.conf to make sure time remains accurate.<br>
</blockquote></div><br></div></div>

--14dae9340893e36fef04bea22476--