Re: probable slight bug in ds1307 RTC driver for year 2100
Hi, David Holland 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
Re: probable slight bug in ds1307 RTC driver for year 2100
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 dholl...@netbsd.org
probable slight bug in ds1307 RTC driver for year 2100
Hi, 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. If someone feels confident enough with all the variations of the chip to straighten this out, that would be nice. The safest way is probably to add individually the DSRTC_FLAG_YEAR_START_2K to chips known indeed to start their counting at year 2000 (might be all of them). Of course all users have to update the date after the change, which is not nice. See sys/dev/i2c/ds1307.c around line 477. Sorry for the long e-mail for a small problem, :-) Aymeric
