Year 2038 problem

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Sep 14 15:09:24 UTC 2011


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.

We have also the watchdog interval.  For example in rtems_timer_fire_when() we have

rtems_time_of_day *wall_time,

rtems_interval seconds = _TOD_To_seconds( wall_time );

and also

       _Watchdog_Insert_seconds(
          &the_timer->Ticker,
          seconds - _TOD_Seconds_since_epoch()
        );

Thus rtems_timer_fire_when() does have a year 2106 problem.

>
> 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.



More information about the users mailing list