Date: Sun, 29 Aug 2004 00:35:55 +0200 From: Brad Knowles <brad@stop.mail-abuse.org> To: Hiroki Sato <hrs@freebsd.org> Cc: sparc64@freebsd.org Subject: Re: 64bit time_t problem? Message-ID: <p06002074bd56b8c38e19@[10.0.1.3]> In-Reply-To: <20040829.054111.102114690.hrs@eos.ocn.ne.jp> References: <20040827.211843.08645408.hrs@eos.ocn.ne.jp> <200408271247.i7RClGku009570@the-macgregors.org> <20040829.054111.102114690.hrs@eos.ocn.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:41 AM +0900 2004-08-29, Hiroki Sato wrote:
> m> AFAIK it's an NTP "issue" - your system is required to be within a
> m> number of years of "now" for it to be set. Trawl
> m> comp.protocols.time.ntp for details, or see the NTP documentation
> m> on the NTP website (www.ntp.org) where I remember this being
> m> discussed in the last few months (sorry I can't be more precise).
>
> Thanks for the pointer. I will look into them.
You definitely don't want to try to use NTP to set the time if
the offset is too large. Modern versions of ntpd can make a one-time
stepping change if you add the "-g" option on the command line, but
even that can only take you so far. While FreeBSD on sparc64 might
now have a 64-bit time_t, but I don't know that the protocol can
handle this large of a difference.
Try setting the date manually to something reasonably close
(i.e., less than 136 years), then using ntpd to get the "real" time.
--
Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/>; for more info.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06002074bd56b8c38e19>