Andrew Cagney wrote:
> 
> > I'm used to NetBSD upon booting, when it finds a preposterous date (e.g.
> > prior to say 1990), setting the clock based upon the date in the booting
> > disk super block.  I've got a Mac with a dead PRAM battery that I keep
> > meaning to replace.  Right now, not only do I have to reset all my OFW
> > settings after a power failure, but I have to remember to boot single
> > user to manually set the date - doing an "ntpdate" does not seem to produce
> > a useful effect.  I notice it says the date is circa 1956 GMT and after
> > the rc.d triggered ntpdate runs I'm around 1933 ...  just curious.
> 
> You might be interested in ``PR bin/13578: ntpdate stuck in the 1930's'' :-)

Yes, that appears to be the same issue - thanks!

So I took a look at macppc/clock.c and can see where the RTC query takes
place and the code proceeds to set the kernel's notion of time and then
if the delta is more than 2 days to gripe about it. (e.g. "Warning: the
clock has lost 15963 days.")

Now comes the hard decision.  Does it make any sense to proceed with setting
the date if the change from the super block FS time stamp is negative, when it
is say off (i.e. negative) by more than a week, a month, a year, a decade?

I could believe there is some situation in which the date could "go backward"
but based upon just travel in time zones, that would only be a day or so.
What else can cause a "reversal of time?"  I suppose the inverse situation,
i.e. when the super block/file system time stamp is trash.

The fact that ntpdate can't groan a totally nutty timewarp is fine with
me.  I know it can handle a delta of say a few days or so.  Thus if there
is too large a negative time warp, I'm suggesting the kernel's notion of
the date/time should instead come from the file system's time stamp @ boot.

Similarly, a RTC value prior to say 1970, 1980, 1990 (you pick the decade)
can be assumed to be bogus and ignored as preposterous...  some RTC hardware
includes a flag/bit indicating whether values are bogus or "good."

Cheers,

-- Ken