ringomaister
07-04-2008, 18:38:02
E:bailar:l problema del año 2038 podría causar que una parte del software fallase en ese año. El problema afecta a los programas que usen la representación del tiempo basada en el sistema POSIX, que se basa en contar el número de segundos 1 de enero de 1970 segundos intercalares) a las 00:00:00 (ignorando los segundos intercalares).
Esta representación es un estańdar de factor en los sistemas tipo Unix y tambien en los programas escritos para muchos otros sistemas operativos debo al gran alcance del lenguaje de programación C. En la mayoría de sistemas de 32 bits, el tipo de dato time_t usado para guardar el contador de segundos es un entero de 32 bits con signo, es decir, que puede representar un rango de números entre -2.147.483.648 y 2.147.486.647 (-231 y 231-1; 1 bit para el signo, y 31 para el valor absoluto), por lo que el último segundo representable con este formato será a las 03:14:07 UTC del 19 de enero de 2038 cuando el contador llegue a 2147483647. Un segundo después, el contador se desbordará, y saltará al valo -2.147.483.648, que causará el fallo de programas que interpretarán el tiempo como que están en 1901 o 1970 (dependiendo de la implementación), en vez de 2038. A su vez, esto causaría cálculo y procesamiento incorrecto.
No hay una forma sencilla de arreglar este problema para las combinaciones existentes de CPU/SO. Cambiar la definición time_t para usar un tipo de 64 bits rompería la compatibilidad binaria para el software, almacenamiento de datos, y, por lo general, cualquier cosa que tenga algo que ver con la representación binaria del tiempo. Cambiar time_t a un entero de 32 bits sin signo afectaría a los programas que hacen cálculos con diferencias de tiempo.
La mayoría de sistemas operativos para arquitecturas de 64 bits utilizan enteros de 64 bits para time_t. La migración a estos sistemas está todavía en proceso y se espera que se complete antes del 2038. Sin embargo, cientos de millones de sistemas de 32 bits son utilizados todavía en el 2007, muchos en sistemas integrados, y no es posible asegurar que todos ellos habrías sido reemplazados antes del 2038.
Usar un entero de 64 bits retrasaría la fecha del problema unos 290 mil millones de años, es decir, mucho tiempo después de que el sol se haya extinguido.
http://upload.wikimedia.org/wikipedia/commons/e/e9/Year_2038_problem.gif (http://es.wikipedia.org/wiki/Segundo_intercalar)
Esta representación es un estańdar de factor en los sistemas tipo Unix y tambien en los programas escritos para muchos otros sistemas operativos debo al gran alcance del lenguaje de programación C. En la mayoría de sistemas de 32 bits, el tipo de dato time_t usado para guardar el contador de segundos es un entero de 32 bits con signo, es decir, que puede representar un rango de números entre -2.147.483.648 y 2.147.486.647 (-231 y 231-1; 1 bit para el signo, y 31 para el valor absoluto), por lo que el último segundo representable con este formato será a las 03:14:07 UTC del 19 de enero de 2038 cuando el contador llegue a 2147483647. Un segundo después, el contador se desbordará, y saltará al valo -2.147.483.648, que causará el fallo de programas que interpretarán el tiempo como que están en 1901 o 1970 (dependiendo de la implementación), en vez de 2038. A su vez, esto causaría cálculo y procesamiento incorrecto.
No hay una forma sencilla de arreglar este problema para las combinaciones existentes de CPU/SO. Cambiar la definición time_t para usar un tipo de 64 bits rompería la compatibilidad binaria para el software, almacenamiento de datos, y, por lo general, cualquier cosa que tenga algo que ver con la representación binaria del tiempo. Cambiar time_t a un entero de 32 bits sin signo afectaría a los programas que hacen cálculos con diferencias de tiempo.
La mayoría de sistemas operativos para arquitecturas de 64 bits utilizan enteros de 64 bits para time_t. La migración a estos sistemas está todavía en proceso y se espera que se complete antes del 2038. Sin embargo, cientos de millones de sistemas de 32 bits son utilizados todavía en el 2007, muchos en sistemas integrados, y no es posible asegurar que todos ellos habrías sido reemplazados antes del 2038.
Usar un entero de 64 bits retrasaría la fecha del problema unos 290 mil millones de años, es decir, mucho tiempo después de que el sol se haya extinguido.
http://upload.wikimedia.org/wikipedia/commons/e/e9/Year_2038_problem.gif (http://es.wikipedia.org/wiki/Segundo_intercalar)