problema técnico de almacenamiento de datos de 32 bits De Wikipedia, la enciclopedia libre
En informática, el problema del año 2038 (conocido también por el numerónimoY2K38) amenaza que podría causar que una gran parte del software falle en ese año. El problema afecta mucho a los programas que usen la representación del tiempo basada en el sistema POSIX (Tiempo Unix), que se basa en contar el número de segundos transcurridos desde la noche del 1 de enero de 1970 a las 00:00:00 (ignorando los segundos intercalares).[1]
Animación del efecto 2038.
Esta representación es un estándar de facto en los sistemas tipo Unix y también en los programas escritos para muchos otros sistemas operativos debido 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 -2147483648 y 2147483647 (-231 y 231-1; 1 bit para el signo, y 31 para representar su valor en complemento a dos), 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 valor -2147483648, que causará el gran fallo de programas que interpretarán el tiempo como que están en 1901 (dependiendo de la implementación), en vez de en 2038. A su vez, esto causaría cálculo y procesamiento incorrecto y causaría un gran problema mundial.
No hay una forma sencilla de arreglar este problema para las combinaciones existentes de CPU/SO. Cambiar la definición de time_t para usar un tipo de 64 bits rompería una gran parte de 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 mucho antes de 2038. Usar un entero de 64 bits retrasaría la fecha del problema a unos 292 mil millones de años (2,9 × 1011). Es decir, 22 veces la edad aproximada del universo.
Muy relacionado con el tema del año 2038 está el año 2036 (numérico: Y2K36). El 7 de febrero de 2036 a las 06:28:16 UTC, el contador del protocolo de sincronización de hora NTP (Protocolo de tiempo de red), ampliamente utilizados en los círculos de Unix, llegará a su máximo valor en muchos dispositivos, especialmente los sistemas integrados, que todavía utilizan el antiguo estándar RFC 868. En las implementaciones modernas, este problema está resuelto en la RFC 5905. En este caso el contexto es que el tiempo de espera se lleva a cabo con un número de 32 bits en segundos, pero sin signo y con la hora de inicio del 1 de enero de 1900 a las 00:00:00 UTC.[2] Con una implementación muy adecuada de los sistemas, no hay mayor problema durante el cálculo, ya que la sincronización de tiempo debería funcionar de acuerdo con un método de diferencia. Si un cliente no conoce la hora actual (inicio en frío en sistemas sin reloj de hardware) y no verifica una fecha mínima (por ejemplo, la fecha de su compilación o la fecha del software NTP), podría probar la fecha 1900-01-01 UTC, que no se puede mostrar en tiempo de Unix y entonces el reloj interno del sistema afectado puede saltar a valores "absurdos", lo que puede conducir a un fallo total.
El Boeing 787 presenta una falla de software que obliga a apagar cada cierto tiempo —y por completo— los sistemas eléctricos a fin de prevenir entrar en modo de fallo, lo que ocasionaría el apagado de los motores en vuelo. La remota posibilidad ocurre en un software contador de centésimas de segundos que se desborda después de poco más de 248 días de funcionamiento continuo (248×24 horas ×3600 segundos ×100 = 2142720000).[3][4][5][6] La Administración Federal de Aviación (FAA) consideró menos peligroso y económico el implementar una directiva de aeronavegabilidad contra sustituir el software de todos los aviones a nivel mundial.[7]
Algunos modelos de unidades de estado sólido vendidos por la empresa Hewlett Packard Enterprise fueron implementados con un contador de horas mientras está encendido.[8] Dicho valor se guardaba en una variable de 2 bytes con signo por lo que al alcanzar las 32 768 horas de uso (215) los datos almacenados solo pudieron ser recuperados mediante una actualización de firmware.[9]
El 8 de agosto de 2013 la sonda espacial Deep Impact tuvo una falla en el conteo del tiempo, lo que ocasionó la mala orientación de sus paneles solares quedando así sin suministro eléctrico para comunicarse y condujo a la finalización de la misión.[10] En este caso el conteo se llevaba a cabo por décimas de segundo en una variable de 32 bits sin signo: 232=4294967296; si sumamos 4294967296 décimas de segundo a la fecha 1 de enero de 2000 resulta 11 de agosto de 2013 12:38:49 a.m.,[11] teniendo en cuenta, además, el fenómeno de la dilatación del tiempo.
De manera similar algunos dispositivos de Sistema de Posicionamiento Global llevan cuenta del tiempo por semanas en un campo de 10 bits (a partir del 6 de enero de 1980),[12] permitiendo un máximo de 1024 semanas (210).[13][14] El primer reinicio ocurrió el 21 de agosto de 1999 (en inglés: GPS Time Epoch), y el segundo el 6 de abril de 2019,[15][16] abriendo la posibilidad de que algunos artefactos tomen como fecha errónea el 5 de enero de 1980. Esto, básicamente, es el mismo problema de desborde de memoria numérica para el año 2038.
El problema hacía que los dispositivos Android se bloquearan y no reiniciaran cuando se establecía la fecha límite.[17] Para comprobar esto se puede ir a la configuración de fecha y hora en el dispositivo, y al tratar de cambiar la fecha y hora al 2038; se encontrará con la sorpresa de que solo le permite cambiarlo hasta el 31 de diciembre de 2037. En la versión 4.0.4 se agregó esta característica, en las versiones anteriores, el calendario mostraba fechas hasta 2104, pero al seleccionar una fecha más adelantada a la fecha límite, el calendario volvía a la fecha actual. El selector de fechas mostraba correctamente los años a simple vista, pero al poner un dedo sobre alguna fecha no contable, este marcaba su negativa, es decir, el 19 de enero de 2040 por ejemplo, a simple vista se veía correcto, pero el sistema marcaba 13 de diciembre de 1903, ya que al reiniciarse, la primera fecha mostrable es 13 de diciembre de 1901. Un dato curioso es que de esta forma el sistema no se tildaba ni reiniciaba, la única manera era dejando que el contador llegara al límite por sí mismo.[17]
En los dispositivos iOS el sistema permite cambiar la fecha hasta el 1 de enero de 2038; sin embargo, desde el iPhone 5s en adelante se solucionaría, ya que estos modelos recientes de iPhone poseen un procesador de 64 bits que lo deja fuera de este problema. Igualmente Android ya está disponible en variantes de 64 bits desde la versión 5.0 por lo que gradualmente dejará atrás este problema. Los dispositivos con Android de 32 bits, Ubuntu Phone, Ubuntu Touch o Firefox OS llegan hasta el 31 de diciembre de 2037. Los dispositivos con Windows Phone 7 permiten llegar hasta el 1 de enero de 2040. Los dispositivos Windows Phone 8 no están afectados, y cuentan fechas desde el año 1601 hasta el 3000, concretamente el 1 de enero, al llegar a las 23:59, el contador regresa 24 horas y vuelve a marcar las 00:00 01/01/3000.
Concretamente, el problema afecta a los programas que usan la representación del tiempo basada en el sistema POSIX, que es el explicado en el párrafo anterior. Es la representación estándar en los sistemas tipo Unix y en todos los programas escritos en el lenguaje de programación C. La mayoría del software actual cae dentro de ese grupo y fallarán, dependiendo de como estén implementados, como si estuviesen funcionando en 1901 o 1970, en vez de en 2038. A pesar de ser un problema bien conocido (los programadores conocen esta limitación desde la implementación misma del lenguaje C), no existe una forma sencilla de solucionar este problema. Podría cambiarse el tipo de variable empleado por un entero de 32 bits sin signo, pero esto haría que todos los programas que hacen cálculos con diferencias de tiempo fallen. Y reescribir por completo esas aplicaciones es un trabajo enorme que solo puede evitarse migrando a los 64 bits.
La tecnología actual va dejando atrás gradualmente los 32 bits. Los mayores fabricantes de procesadores (Intel, AMD, Qualcomm, MediaTek y otros) ofrecen microprocesadores de 64 bits desde hace tiempo. También los desarrolladores de sistemas operativos han evolucionado hacia la plataforma de 64 bits:
Microsoft ofrece versiones de Windows de 64 bits desde Windows XP, además la actual versión Windows 11 no cuenta con versiones de 32 bits.
En macOS solo existen versiones en 64 bits desde Mac OS X 10.7
En GNU/Linux existe en versiones de 64 bits desde el año 2003, Debian desde 2016 ha acelerado su desarrollo en procesadores de 64 bits.[18][19]
De esta forma si hoy en día los 32 bits ya están siendo reemplazados, difícilmente seguirán en uso en 2038. Si todavía quedaran sistemas embebidos operando con 32 bits para aquel entonces, los fabricantes tendrían bastante tiempo para reparar el problema mediante actualizaciones.[21]
Solución para Kernel Linux
Resolver esta limitación de fecha en el sistema operativo Linux llevó a modificar todos los subsistemas e incluso más.[22] Para resolverlo se echó mano de Espacio de usuario, la Biblioteca estándar de C, POSIX, y donde la tarea resultó ser más difícil fue en el campo del Sistema de archivos virtual debido al uso de estructuras de estampado de tiempo de 64 bits (struct timespec64) en los inodo.[23] En junio de 2016 Linus Torvalds objetó uno de los cambios propuestos;[24] para junio de 2018 se pudo agregar al kernel todos los cambios propuestos y el problema fue solucionado.[25]
List, Jenny (1 de enero de 2020). «Happy 50th Birthday To All You Epoch Birthers»(html). Hack a Day(en inglés). Archivado desde el original el 1 de enero de 2020. Consultado el 1 de enero de 2020. «The earliest UNIX time was thus measured in terms of the American mains power frequency, 60ths of a second with an epoch at the start of 1971. Since a 32 bit number at that rate would have meant a very short time before roll-over it was decided to use seconds instead with an epoch at the start of the decade. The latest distributions might have switched to using a 64-bit integer because the original 32-bit one would roll over in 2038, but otherwise the timing scheme remains unchanged.»
«NTP Timescale and Leap Seconds»(html). NTP org(en inglés). Archivado desde el original el 3 de noviembre de 2011. Consultado el 12 de octubre de 2018. «With respect to the recent year 2000 issue, the most important thing to observe about the NTP timescale is that it knows nothing about days, years or centuries, only the seconds since the beginning of the current era which began on 1 January 1900. On 1 January 1970 when Unix life began, the NTP timescale showed 2,208,988,800 and on 1 January 1972 when UTC life began, it showed 2,272,060,800.»
Pottier, jean-Marie (1 de mayo de 2015). «L'étonnant bug qui pourrait priver un Boeing 787 de courant en plein vol»(html). Slate(en francés). Archivado desde el original el 3 de mayo de 2015. Consultado el 12 de octubre de 2018. «C'est un étonnant (et, potentiellement, un peu inquiétant) bug aéronautique que rapportent plusieurs médias américains: la FAA, l'autorité américaine de l'aviation civile, a ordonné, jeudi 30 avril, aux compagnies opérant des Boeing 787 Dreamliner de couper de manière périodique l'alimentation électrique des générateurs de l'avion, afin d'éviter un bug qui pourrait causer leur panne simultanée. Durant des tests, le constructeur a en effet constaté que si ces générateurs étaient constamment sous tension pendant 248 jours (8 mois), cela engendrait un bug qui interrompait leur alimentation électrique. Si tous les générateurs de l'avion avaient été mis sous tension simultanément, ils pourraient donc tomber en panne simultanément, y compris en plein vol.»
«Airworthiness Directives; The Boeing Company Airplanes»(pdf). Administración Federal de Aviación(en inglés). 23 de abril de 2015. Archivado desde el original el 24 de enero de 2017. Consultado el 12 de octubre de 2018. «We are adopting a new airworthiness directive (AD) for all The Boeing Company Model 787 airplanes. This AD requires a repetitive maintenance task for electrical power deactivation on Model 787 airplanes. This AD was prompted by the determination that a Model 787 airplane that has been powered continuously for 248 days can lose all alternating current (AC) electrical power due to the generator control units (GCUs) simultaneously going into failsafe mode. This condition is caused by a software counter internal to the GCUs that will overflow after 248 days of continuous power. We are issuing this AD to prevent loss of all AC electrical power, which could result in loss of control of the airplane.»
Trimble, Stephen (30 de abril de 2015). «FAA orders new 787 electrical fix to prevent power failure»(html). Flight Global(en inglés). Archivado desde el original el 3 de mayo de 2015. Consultado el 12 de octubre de 2018. «All Boeing 787 operators will be required to periodically deactivate the electrical system to avoid a problem with a newly-discovered software bug that could cause the aircraft to lose alternating current (AC) power, the US Federal Aviation Administration says in a new airworthiness directive.»
«ANA, JAL say their Dreamliners safe from mid-flight shutdown glitch»(html). The Japan Times(en inglés). 1 de mayo de 2015. Archivado desde el original el 7 de mayo de 2015. Consultado el 12 de octubre de 2018. «All Nippon Airways Co. and Japan Airlines Co. said Friday that their Boeing 787 Dreamliners won’t be affected by a recently discovered software error that could result in a total loss of power even during flight.»
Andy Pasztor y Jon Ostrower (30 de abril de 2015). «FAA Warns 787s Can Lose All Electrical Power in Certain Circumstances»(html). The Wall Street Journal(en inglés). Archivado desde el original el 3 de mayo de 2015. Consultado el 12 de octubre de 2018. «Nearly four years after Boeing Co.’s 787 Dreamliner entered commercial service, federal regulators are moving to combat a potentially dangerous software glitch they said can cause a total loss of electrical power that would endanger the aircraft.»
Llascu, Ionut (26 de noviembre de 2019). «HP Warns That Some SSD Drives Will Fail at 32,768 Hours of Use»(html). Bleeping Computer(en inglés). Archivado desde el original el 23 de diciembre de 2019. Consultado el 1 de enero de 2020. «Hewlett Packard Enterprise (HPE) released firmware updates for a number of its Serial-Attached SCSI solid-state drives to prevent their failure at exactly 32,768 hours of operation time.»
Cassely, Jean-Laurent (6 de mayo de 2015). «2.147.483.647: pourquoi ce nombre peut tout faire buguer et rend fous les informaticiens»(html). Slate(en francés). Archivado desde el original el 9 de mayo de 2015. Consultado el 12 de octubre de 2018. «L'article de la BBC raconte que c'est aussi ce bug qui est soupçonné d'avoir causé la perte de contact par la Nasa en 2013 de sa sonde spatiale Deep Impact.»
Wallace, Malcolm (23 de septiembre de 2013). «Re: [tz] Deep Impact: wrong time zone?»(html). Gmane Org.(en inglés). Archivado desde el original el 2 de octubre de 2013. Consultado el 12 de octubre de 2018. «Put another way, if you represented time as the number of tenths of a second since midnight on January 1, 2000, then you would hit 4294967296 tenths of a second on August 11, 2013[2]. 4294967296 is significant because it's 2^32, which is the smallest number that can't be represented as a 32-bit integer. Generally this will wrap around to 0 (as in calculating 4294967295 + 1 will give you 0).»
Dunn, Michael (8 de marzo de 2012). «Global Positioning System Directorate Systems Engineering & integration Interface Specification IS-GPS-200»(pdf). Guardia Costera de Estados Unidos(en inglés). p.52. Archivado desde el original el 5 de enero de 2019. Consultado el 12 de febrero de 2019. «The GPS week numbering system is established with week number zero (0) being defined as that week which started with the X1 epoch occurring at midnight UTC (USNO) on the night of January 5, 1980/ morning of January 6, 1980. The GPS week number continuously increments by one (1) at each end/start of week epoch without ever resetting to zero. Users must recognize that the week number information contained in the Nav Message may not necessarily reflect the current full GPS week number».
«CGSICGPS Week Roll Over Issue»(pdf). Official U.S. government information about the Global Positioning System (GPS) and related topics(en inglés). 26 de septiembre de 2017. Archivado desde el original el 22 de enero de 2019. Consultado el 13 de febrero de 2019. «GPS Time as defined in the legacy GPS navigation message (ICD-200), uses 10 bits to count GPS Week Numbers. This representation can only cover a finite period of 1024 weeks(19.7 year epoch).»
Jones, Rhett (7 de marzo de 2019). «The Y2K Moment For GPS Systems Is Just a Month Away»(html). Gizmodo(en inglés). Archivado desde el original el 9 de marzo de 2019. Consultado el 12 de marzo de 2019. «GPS was originally designed to timestamp signals using a system that counts weeks using a 10-digit field that tops out at 1024 weeks(~19.7 years).»
«MEMORANDUM FOR U.S. OWNERS ANDOPERATORS USING GPS TO OBTAIN UTC TIME (sic)»(pdf). National Cybersecurity and Communications Integration Center(en inglés). Archivado desde el original el 29 de abril de 2018. Consultado el 13 de febrero de 2019. «AGPS device that conforms to the latest IS-GPS-200 and provides UTC should not be adversely affected. However, tests of some GPS devices revealed that not all manufacturer implementations correctly handle the April 6, 2019 WN rollover. Additionally, some manufacturer implementations interpret the WN parameter relative to a date other than January 5, 1980.These devices should not be affected by the WN rollover on April 6, 2019 but may experience a similar rollover event at afuture date. For example, a particular GPS device may interpret the WN parameter relative to a firmware creation date and wouldexperience a similar rollover event 1024 weeks afterthat firmware creation date.»
Ortíz, David (16 de octubre de 2014). «Todas las novedades en Android 5.0 (Lollipop)»(html). Xataka. Archivado desde el original el 18 de octubre de 2014. Consultado el 31 de diciembre de 2019. «Android 5.0 llega con soporte a procesadores de 64 bits, tanto en núcleos ARM como x86 o MIPS, manteniéndose compatible también con los procesadores de 32 bits.»
«Qué es el "Efecto 2038", a qué dispositivos afecta y qué peligro podría suponer»(html). Xataka. 23 de septiembre de 2017. Archivado desde el original el 23 de septiembre de 2017. Consultado el 12 de octubre de 2018. «E incluso en el caso de que aún quedase algún sistema de red o dispositivo secundario anclado en los 32 bits por aquel entonces, los fabricantes tienen tiempo de sobra para parchearlos con actualizaciones de software. Vamos, que va a ser muy difícil que este problema de 2038 acabe causando algún estrago significativo.»
Dinamani, Deepa (21 de enero de 2019). «Solving the Year 2038 problem in the Linux kernel»(html). Open Source Dot Com(en inglés). Archivado desde el original el 21 de enero de 2019. Consultado el 29 de enero de 2019. «I chose to work on the Y2038 problem because it let me touch all the subsystems in the kernel—and even more than that. The problem also involves user space, C library, POSIX, and C standards. I found that the problem is really about interfaces between layers.»
Dinamami, Deepa (21 de enero de 2019). «Solving the Year 2038 problem in the Linux kernel»(html). Open Source Dot Com(en inglés). Archivado desde el original el 21 de enero de 2019. Consultado el 29 de enero de 2019. «The problem: The in-kernel representation of inode timestamps was in struct timespec, which is not Y2038 safe. The proposed solution: Change the representation to struct timespec64, which is Y2038 safe.»
Torvalds, Linus (9 de junio de 2016). «Re: [PATCH 02/21] fs: ext4: Use current_fs_time() for inode timestamps»(html). LKML Archive(en inglés). Archivado desde el original el 28 de enero de 2019. Consultado el 29 de enero de 2019. «All existing users and all the ones in this patch (and the others too, although I didn't go through them very carefully) really would prefer just passing in the inode directly, rather than the superblock. So I don't want to add more users of this broken interface. It was a mistake to use the superblock. The fact that the time granularity exists there is pretty much irrelevant. If every single user wants to use an inode pointer, then that is what the function should get.»
Dinamani, Deepa (5 de junio de 2018). «vfs: change inode times to use struct timespec64»(html). Kernel Org(en inglés). Archivado desde el original el 29 de enero de 2019. Consultado el 29 de enero de 2019. «struct timespec is not y2038 safe. Transition vfs to use y2038 safe struct timespec64 instead.»
