David Burgess wrote:
> 
> 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.
>
> 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.

This is certainly where I am coming from also.  I can't see why a time
reversal of more than 24 hours makes any sense.

But I'm trying to put myself into macppc/clock.c and decide what do we
have in the way of information and what can we trust.

We certainly know that a RTC can present bogus data.  Can we trust the
time stamp passed to us, which I believe is the time stamp from our boot
fs super block?

If we do recognition (e.g. magic number) and validation (e.g. checksum
or signature) on our super block, then our fs time stamp should be valid,
or at least as valid as the system time when the fs was last sync'ed.

Thus I agree, I think any time reversal, based upon our RTC and fs
time stamp should choose the fs value and produce a RTC warning.

This should not stop someone from setting their RTC to a prior date, I
believe it is intended only to distinguish when our RTC has gone bogus
and differs in a "cannot happen" sort of way from all other data available.