On Sun, Apr 27, 2014 at 6:30 PM, Chris Johns <chr...@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 > 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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
