For architectures/boards which use the to_tm function in /rtc/date.c (which is alot)
Dates up to 19Jan2038 03:14:08 work fine, but dates after don't:
BOOT> date 011903142038 Date: 2038-01-19 (Tuesday) Time: 3:14:01
BOOT> date Date: 2038-01-19 (Tuesday) Time: 3:14:03
BOOT> date Date: 2038-01-19 (Tuesday) Time: 3:14:04
BOOT> date Date: 2038-01-19 (Tuesday) Time: 3:14:06
BOOT> date Date: 1970-01--24854 (Saturday) Time: -3:-14:-7
BOOT> date Date: 1970-01--24854 (Saturday) Time: -3:-14:-3
BOOT> date Date: 1970-01--24854 (Saturday) Time: -3:-13:-59
This is due to the file the function math, or definition, depending what/where you think the bug is. (or if you think it is a bug at all).
void to_tm(int tim, struct rtc_time * tm)
because tim is a signed int, dates past 19Jan2038 03:14:08 show up as 1970 with negative days/hours. (ie. the date of 01jan2039 shows up as 1970-01--24507 (Wednesday) Time: -5:-27:-15)
Potential solutions: 1) fix math, so negative years show up as years : dates can be set from 1902 to 2038 : 102 years ago, to 34 years in the future). OR 2) change function to be defined as: void to_tm(unsigned int tim, struct rtc_time * tm) which allows things to work until 2106, with existing math. OR 3) leave it alone, by 2010 everyone will have moved to 64-bit time_t, and things will be OK. OR 4) error if someone tries to set the date past 19Jan2038 03:14:08 (this is what Suse 9.0 does). I never checked to see what happens if I let Linux roll over - I didn't feel like crashing my workstation for test purposes, however, then you still need to do #1 above. I will check it out on an embedded target tomorrow.
Because this affects so many architectures/boards, I thought I would ask: a) Does anyone care? b) What is the preferred method to fix? (I tried option 2, because it is the most trivial, and it seems to work fine for me).
Thoughts? Opinions?
-Robin