[U-Boot-Users] Is this a bug? /rtc/date.c

[Robin Getz]

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