Ken Wellsch wrote:
> 
> 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.


It never makes sense for the system to 'automatically' lose more than 
23 hours.  Even then, the RTC in most of the NetBSD systems (I'm not
as familiar as I want to be with the Macs) is maintained in UTC, so
I can't think of a typical application where the clock would lose 
any time at all.  Thanks to the ntp.drift file and the drift boot
string someone posted the other day, any really big change should
probably fail.  Using "ntpdate -B" can be used by hand to make
these pathological changes.

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

A RTC entry that's older than the creation date on the root 
partition is clearly 'bogus enough'.

Since the NetBSD clock starts at Midnight, Jan 1, 1970, I'd say any 
automatic real-time clock setting before that could be considered 
bogus.  As far as I know, NetBSD still isn't 2033 compliant, so there
are definitely some changes in the future on how the RTC is handled.

Dave