Year 2038 problem

[Joel Sherrill]

These haven't been reviewed for a while but were accurate when written. The score tod changed around 4.8 to use timespec or u64 nanoseconds since epoch so score tod overflow are out of date. Should annotate it is some version and older.

http://www.rtems.com/wiki/index.php/TimeRepresentationLimits

This used to be in the faq

 http://www.rtems.com/onlinedocs/releases/rtemsdocs-4.6.5/share/rtems/html/FAQ/FAQ00098.html

I swear I have a report on this issue but am on travel. I will try to find it when I can.

--joel

Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:

>Thanks Joel for the hints.  What is the name of the wiki page?
>
>On 08/17/2011 04:53 PM, Joel Sherrill wrote:
>> The answer somwhat depends on the version but for recent versions this email will cover the basics:
>>
>> + libc time types.. you got this one. We would have to change to unsigned (if OK) or 64 bits
>> + super core tod has two representations. Now the default is struct timespec with time_t issues. There is an alternative choice there which is 64 bits since posix epoch. That one is valid for about 500 years.
>>
>> The internal 64 bit tod representation benchmarked the same on the cpus I checked but we have never gotten buy in for switching to it. It could be switched easily if we agree. All code is there and I intended to allow ports to pick the representation that was best for them.
>>
>> I wrote up all of the time overflow issues year ago. It is the wiki. If it isn't clear or missed something, ask
>>
>> --joel
>>
>> Sebastian Huber<sebastian.huber at embedded-brains.de>  wrote:
>>
>>> Hello,
>>>
>>> since time_t is usually defined as long in Newlib and thus 32-bit on most RTEMS
>>> targets, we are affected by the year 2038 problem:
>>>
>>> http://en.wikipedia.org/wiki/Year_2038_problem
>>>
>>> Has someone already thought about this?
>>>
>>> We have a system that should operate for 30 years.  Has someone already
>>> analyzed if RTEMS can run that long, e.g. which variables may overflow?
>>>
>>> Kind regards,
>>> 	Sebastian
>>>
>>> --
>>> Sebastian Huber, embedded brains GmbH
>>>
>>> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>>> Phone   : +49 89 18 90 80 79-6
>>> Fax     : +49 89 18 90 80 79-9
>>> E-Mail  : sebastian.huber at embedded-brains.de
>>> PGP     : Public key available on request.
>>>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>
>
>-- 
>Sebastian Huber, embedded brains GmbH
>
>Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>Phone   : +49 89 18 90 80 79-6
>Fax     : +49 89 18 90 80 79-9
>E-Mail  : sebastian.huber at embedded-brains.de
>PGP     : Public key available on request.
>
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.