Solo por curiosidad, ¿qué pasará con los modelos RPis A y B el 19 de enero de 2038 en 3:14:07 GMT? ¿Están afectados por el error Y2K38 ?
time_t
, convirtiéndolo en el problema Y292G , que ni nosotros ni el sol viviremos para ver.
Solo por curiosidad, ¿qué pasará con los modelos RPis A y B el 19 de enero de 2038 en 3:14:07 GMT? ¿Están afectados por el error Y2K38 ?
time_t
, convirtiéndolo en el problema Y292G , que ni nosotros ni el sol viviremos para ver.
Respuestas:
Aquí está el resultado de una sesión SSH para mi Pi que ejecuta OpenELEC.
Se cuelga después de llegar a Y2K38. No solo la sesión SSH misma deja de responder, sino que OpenELEC también se congela.
Espero (¡y espero!) Que para 2038 se haya lanzado una solución.
Eso, o su pregunta recibirá muchos votos positivos en 24 años.
En realidad, el Raspberry Pi (hardware) estará bien. No contiene un RTC, por lo que dependerá del sistema operativo que utilice.
Pero IIRC todas las versiones de 32 bits de Linux tienen este problema. Hace algún tiempo (10 años más o menos), Linus dijo que no estaba interesado en arreglar esto en plataformas de 32 bits y todas las plataformas Linux de 64 bits en ese momento tenían 64 bits de time_t. Puede que haya cambiado de opinión desde entonces, por supuesto. El mejor enlace a esto que puedo encontrar es http://permalink.gmane.org/gmane.linux.kernel/1184914 , que no es lo mismo, pero expresa una intención similar.
No será algo particularmente difícil de cambiar, pero forzaría un cambio en las ABI del núcleo. Lo cual es un problema en sí mismo.
Pero, RiscOs usa un tiempo de 40 bits (centisegundo), pero con una Época diferente. ( https://www.riscosopen.org/wiki/documentation/show/OS_Word%2014_3 ) - Hago ese fallo en algún momento en 2318 - [calc fue: 1970 + ((2 ^ 40) / 100) / (60 * 60 * 24 * 365.25)]
Android, por supuesto, usa el kernel de Linux. Y estoy seguro de que me he perdido otras opciones.
Como se implementa actualmente, la Raspberry Pi sufrirá el destino del error enumerado, si no se realizan cambios en el software.
La mayoría de las máquinas modernas están dando el salto a los procesadores de 64 bits, pero no me sorprendería en absoluto ver todavía procesadores incorporados de 32 bits en ese momento. Hay soluciones de software que podrían y tendrán que resolver el problema.
Me parece que la solución más probable sería actualizar Epoch time para comenzar en algo así como el 1 de enero de 2000. Si bien esto no retrasaría el error, sin duda lo restablecería en el futuro previsible.