Year 2038 problem

[Joel Sherrill]

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