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

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Oct 18, 2016 at 09:49:34PM +0200, Aymeric Vincent wrote:
 > in order to avoid breaking working setups using a dsrtc at iic, I
 > introduced a flag DSRTC_FLAG_YEAR_START_2K to impose a base year of 2000
 > on a per-chip basis. The existing code starts at POSIX_BASE_YEAR (1970),
 > with the comment:
 > 
 > /* XXX: Should be an MD way to specify EPOCH used by BIOS/Firmware */
 > 
 > However, in order to keep track of the date on chips which use the
 > day/month/year format (not all of them), the year needs to be consistent
 > with what the chip believes, if leap years are to be accounted for
 > correctly.
 > 
 > I'm afraid in 2100, these chips which we offset by 30 years in the code
 > will believe the year is a leap year (2070) when it's actually not (2100),
 > and the reciprocal problem will arise in 2130.

I don't understand. The clock hw has its own base year, so assuming
the clock hw doesn't have any leap year bugs itself, it will give you
the right day after Feb. 28 as long as you use the right base year
when loading the time into it.

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

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

-- 
David A. Holland
dholland%netbsd.org@localhost