[PATCH] rtems: Fix sp2038 test.
gedare at rtems.org
Mon Apr 28 00:05:15 UTC 2014
On Sun, Apr 27, 2014 at 6:30 PM, Chris Johns <chrisj at rtems.org> wrote:
> 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.
+1, if there is still a 2038 problem then the test should be expanded
to expose it.
>> 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
> 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.
> rtems-devel mailing list
> rtems-devel at rtems.org
More information about the devel