On 2014-04-28 00:30, Chris Johns 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.
Yes, it fixes the test, but it doesn't fix the problem. Anyone using the POSIX
date and time API uses the Newlib code.
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.
I would rather fix this problem later.
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.
I guess we will have a RTEMS 4.12 or so before 2038, so there is no immediate
need to fix it now.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
