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
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
