Year 2038 problem

[Sebastian Huber]

Hello,

On 08/17/2011 04:53 PM, Joel Sherrill wrote:
> + 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.

I started to write a test case that examines the year 2038 readiness of RTEMS:

testsuites/sptests/sp2038

Even with 64-bit timestamps we have the problem that rtems_clock_get_tod() is 
only correct up to 2038-01-19Z03:14:07.  The problem is that we use gmtime_r() 
internally to convert the seconds since UNIX epoch (uint32_t) into a struct tm 
and this into rtems_time_of_day.

The rtems_clock_set() and rtems_clock_get_seconds_since_epoch() on the other 
hand are correct up to 2106-02-07Z06:28:15.

I think there is no reasonable way to avoid a 64-bit signed time_t if you want 
to make your system year-2038-ready.

Have a nice day!

	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.