Re: probable slight bug in ds1307 RTC driver for year 2100

[Aymeric Vincent <aymericvincent%free.fr@localhost>]

Hi,

David Holland <dholland-tech%netbsd.org@localhost> writes:

> If, however, you use a base year that's off by 30 when programming it,
> it won't be wrong in 2100, it will be wrong *now* -- it is 2016 so if
> you loaded the time using a base year of 1970 when the clock actually
> expected 2000, it will think it's 2046 (not a leap year) and will have
> skipped this past Feb. 29th. (Or if it's the other way around, 1986,
> which was also not a leap year.)

Oh, you're right! My bad, I handled 30 as if it were divisible by 4,
which it isn't. So it's already wrong, if I didn't miss something else.

The thing is, for it to show, you need to have the computer off during
the night of Feb 28th, otherwise the date keeping is (correctly) done by
the kernel, and saved to the rtc only on shutdown/reboot.

> Also I don't see why you'd introduce a magic flag rather than just a
> #define for the proper year value to use...

Well, my expectation is that all the day/month/year versions of the
chips handled by the driver will have to be based on 2000, and the
others can keep 1970 as their base value. We would need a per-chip
integer in the struct if we need something more fine grained.

Regards,
 Aymeric