Bizarre date....

I am having a weird issue on my TS-7000 (arm9) board. It's running Debian
sarge. When I set the date with ntpdate or ntpd, it is set to Sep. 11
1937.....

This is a real problem.....

I can't figure out why it's doing this. An identically configured x86
system doesn't have this problem....

Any suggestions are welcome; I am stumped......

Is this a known issue? I've filed a support request with the
manufacturer, but I know that the depth of knowledge out here can be
pretty awesome, so I'm hoping that someone has some idea where I should
look.....

On Thu, 29 Sep 2005 20:13:46 -0700, Captain Dondo
<(E-Mail Removed)> wrote:
> I am having a weird issue on my TS-7000 (arm9) board. It's running Debian
> sarge. When I set the date with ntpdate or ntpd, it is set to Sep. 11
> 1937.....
>
What happens when you set the date with date or hwclock? Have you tried
"ntpdate -d" or "ntpdate -q"?


--
Never try to outstubborn a cat.
-- Lazarus Long, "Time Enough for Love"

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) >, Captain Dondo wrote:

>I am having a weird issue on my TS-7000 (arm9) board. It's running Debian
>sarge. When I set the date with ntpdate or ntpd, it is set to Sep. 11
>1937.....

Hmmm... man date then try "date + %s" without the quotes.

>Date: Thu, 29 Sep 2005 20:13:46 -0700

The _difference_ between those dates is roughly 24855 days, or 2147472000
seconds... has that raised a flag yet? 2147472000 = 0x7FFFD280

>This is a real problem.....

No kidding.

>I can't figure out why it's doing this. An identically configured x86
>system doesn't have this problem....

I can't see _why_ it's happening, but there may be the "what" is happening.
By the way, posting this to "comp.protocols.time.ntp" might be interesting
for some - I'm sure Professer Mills would get a bang out of it. There may
even be someone there who can stop laughing long enough to give an answer
as to what on earth it might be doing.

Old guy

On Fri, 30 Sep 2005 19:09:49 -0500, Moe Trin wrote:
>
> I can't see _why_ it's happening, but there may be the "what" is happening.
> By the way, posting this to "comp.protocols.time.ntp" might be interesting
> for some - I'm sure Professer Mills would get a bang out of it. There may
> even be someone there who can stop laughing long enough to give an answer
> as to what on earth it might be doing.
>

Apparently this is a known 'feature' - ntpdate picks the date nearest the
currect system time modulo some large number of seconds (64 years)....

Since the system boots with the clock set to 1967, 1937 is closer than
2005, so ntpdate picks 1937 as the 'correct' date....

The workaround is to set the system date to something more realistic -
like 1 jan 2000 - before running ntpdate.

But ntpdate is deprecated and should be replaced by ntpd -q or some
such.... I have not kept up with ntpd much - usually it just works
magically.

In the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed)> , Captain Dondo wrote:

>Apparently this is a known 'feature' - ntpdate picks the date nearest the
>currect system time modulo some large number of seconds (64 years)....

Search for the variable 'time_t'. On a 32 bit system, it's a signed long
meaning the maximum value is 2147483647 seconds, or 68 years 18 days 3.23
hours. When we all finally move to 64 bit systems, the signed long is
9223372036854775807 - which is 292.27 billion (e9) years. Someone will
need to replace the battery on the sun (and maybe the universe) before
that one rolls over,

>Since the system boots with the clock set to 1967, 1937 is closer than
>2005, so ntpdate picks 1937 as the 'correct' date....

Got it. Why is the system starting with 1967? No CMOS clock?

Old guy