[U-Boot-Users] RTC Question
All:
General question, in the specific processor (Blackfin BF533) that I am using, the on-board RTC can have a 32768 days, and defaults to starting at 01Jan1970. This means that RTC rollover will occur around Fri, 19-Sep-2059 11:59pm. On Sat 20-Sep-2059, the date will be displayed as Thur 01-Jan-1970.
Should I add extra complexity, to extend things past this?
I see issues in other code that will roll over around 19Jan2038, so I would expect that others are not concerned about it?
-Robin
In message 6.1.1.1.0.20041008090220.01e07ec0@wheresmymailserver.com you wrote:
General question, in the specific processor (Blackfin BF533) that I am using, the on-board RTC can have a 32768 days, and defaults to starting at 01Jan1970. This means that RTC rollover will occur around Fri, 19-Sep-2059 11:59pm. On Sat 20-Sep-2059, the date will be displayed as Thur 01-Jan-1970.
Should I add extra complexity, to extend things past this?
Hou could you fix this? U-Boot will probably not even be running when the rollover happens, so it has zero chance to notice. Of course you can assume that no board will ever show a legal time before 2004, so you could always add of offset equivalent to 34 years to your RTC's date, shifting the problem until 2093 ... The offset is trivial to implement, and probably all you ever need.
Best regards,
Wolfgang Denk
--- Wolfgang Denk wd@denx.de wrote:
In message
Hou could you fix this? U-Boot will probably not even be running when the rollover happens,
I seem to recall the Cobol programmers saying this before Y2K.:-)
_______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
In message 20041008215519.11048.qmail@web13827.mail.yahoo.com you wrote:
Hou could you fix this? U-Boot will probably not even be running when the rollover happens,
I seem to recall the Cobol programmers saying this before Y2K.:-)
I think you misinterpret my statement.
I mean that U-Boot is just a boot loader, used mostly in embedded systems which often run in 24/7/365.25 mode. Only a tiny fraction of the total system time will ever be spent in U-Boot. Chances that the roll-over happens while an OS (or some other software) is running are magnitudes bigger than that we see this event in U-Boot.
So calculate the probability that (1) the same hardware will still be used in 2094, (2) it will still run U-Boot, and (3) the roll-over happens exactly during a reboot of the system.
Now how much effort do you intend to spend on solving such a problem?
My recommendation is: document and ignore it. It's a feature (read: limitation) of the hardware, and this type of hardware will go out of existence soon enough.
Best regards,
Wolfgang Denk
11:59pm. On Sat 20-Sep-2059, the date will be displayed as Thur 01-Jan-1970.
Should I add extra complexity, to extend things past this?
I see issues in other code that will roll over around 19Jan2038, so I would expect that others are not concerned about it?
This is a common discussion on many boards. Actually, most variants of Linux will roll over in 2038. Eventually (within the next five years, I'm guessing) the move will probably be made to 64-bit clocks. It's not a matter of 32768 days, but 2^31-1 seconds (for signed int), so a 64-bit clock will push out the rollover to the year 292,271,025,015 (roughly), or about 50 times the age of our solar system.
Considering that 2038 is 34 years away, though (remember that 34 years ago was 1970) it's pretty likely that hardware is going to be considerably different by then, and anything made today will be a distant memory. I could be wrong. Anybody still running embedded devices made in 1970?
Victor Wren
participants (4)
-
Frank -
Robin Getz -
Victor Wren -
Wolfgang Denk