[PATCH] rtems: Fix sp2038 test.

[Chris Johns]

On 27/04/2014 10:23 pm, Sebastian Huber wrote:
> On 04/27/2014 10:17 AM, Chris Johns wrote:
>> Avoid using newlib's gmtime_r call which fails with a max signed int.
>> Add an RTEMS specific version for 1/1/1988 to 31/12/2100.
>>
>> Update sp2038 to test every day from 1/1/1988 to 31/12/2100. Only days
>> need be tested as the code splits the seconds based on days.
>
> This doesn't solve the problem with the year 2038 problem for the UNIX
> 32-bit time.

The test is about an RTEMS API that fails and the patch fixes the test.

> I don't think we should duplicate the time code and
> instead use the one from Newlib.

I would rather have RTEMS contain and control this code at this point in 
time.

If you wish to switch to a 64bit time_t and validate it and then do a 
performance test for this API against newlib please do however until 
then we should run with this change and fix the test and the RTEMS API.

> We should change time_t to 64-bit instead.

I do not think we should change this at this late stage of the release 
cycle. If we keep delaying we may just need a 2038 fix for 4.11 and I 
will need a 46 point font to see.

Chris