Articulo de referencia

Problema del año 2038

Una representación visual animada del error en acción. El error de desbordamiento ocurrirá a las 03:14:08 UTC del 19 de enero de 2038. El problema del año 2038 (también conocido...

Una representación visual animada del error en acción. El error de desbordamiento ocurrirá a las 03:14:08 UTC del 19 de enero de 2038.

El problema del año 2038 (también conocido como Y2038 , [ 1 ] Y2K38 , supererror Y2K38 o Epochalypse [ 2 ] [ 3 ] ) es un problema de cálculo del tiempo que deja a algunos sistemas informáticos incapaces de representar tiempos posteriores a las 03:14:07 UTC del 19  de enero  de 2038.

El problema se presenta en sistemas que miden el tiempo Unix (el número de segundos transcurridos desde la época Unix [00:00:00 UTC del 1  de enero  de 1970]) y lo almacenan en un entero con signo de 32 bits . Cuando se supera el valor máximo del tipo de dato , el entero se desborda a su valor mínimo, que los sistemas interpretan como pasado. El problema se asemeja al problema del año 2000 , pero surge de las limitaciones de la representación del tiempo en base 2 (binaria), en lugar de base 10 .

Los sistemas informáticos que utilizan el tiempo para cálculos críticos pueden sufrir errores fatales si no se soluciona el problema del año 2038. Algunas aplicaciones que utilizan fechas futuras ya han encontrado este fallo. [ 4 ] [ 5 ] Los sistemas más vulnerables son aquellos que se actualizan con poca frecuencia o nunca, como los sistemas heredados y embebidos . Los sistemas modernos y las actualizaciones de software solucionan este problema utilizando enteros con signo de 64 bits , que tardarán 292 mil millones de años en desbordarse, aproximadamente 21 veces la edad estimada del universo . [ 6 ]

Causa

Muchos sistemas informáticos miden la hora y la fecha utilizando el tiempo Unix , un estándar internacional para la medición del tiempo digital. El tiempo Unix se define como el número de segundos transcurridos, sin tener en cuenta los segundos intercalares , desde las 00:00:00 UTC del 1 de enero de 1970, fecha conocida como época Unix .

Históricamente, el tiempo Unix se ha codificado como un entero de 32 bits con signo , un tipo de dato compuesto por 32 dígitos binarios (bits) que representan un valor entero, donde "con signo" significa que el número puede representar tanto números positivos como negativos, así como cero; y generalmente se almacena en formato de complemento a dos . [ a ] ​​Por lo tanto, un entero de 32 bits con signo solo puede representar valores enteros desde −(2 31 ) hasta 2 31  1 inclusive. En consecuencia, si se utiliza un entero de 32 bits con signo para almacenar el tiempo Unix, el último tiempo que se puede almacenar es 2 31  1 ( 2 147 483 647 ) [ b ] segundos después de la época, que es 03:14:07 UTC del 19 de enero de 2038 . [ 7 ] Los sistemas que intenten incrementar este valor en un segundo más a 2 31 segundos después de la época ( 03:14:08 ) sufrirán un desbordamiento de enteros , inadvertidamente cambiando el bit de signo para indicar un número negativo. Esto cambia el valor entero a −(2 31 ), o 2 31 segundos antes de la época en lugar de después , lo que los sistemas interpretarán como 20:45:52 UTC del 13 de diciembre de 1901. A partir de aquí, los sistemas continuarán contando hacia arriba, hacia cero, y luego hacia arriba a través de los enteros positivos nuevamente. Como muchos sistemas informáticos utilizan cálculos de tiempo para ejecutar funciones críticas, el error puede introducir serios problemas.

Sistemas vulnerables

Cualquier sistema que utilice estructuras de datos con representaciones de tiempo de 32 bits con signo tiene un riesgo inherente de fallar. Es prácticamente imposible obtener una lista completa de estas estructuras de datos, pero existen estructuras de datos bien conocidas que presentan el problema del tiempo de Unix:

  • Sistemas de archivos que utilizan 32 bits para representar tiempos en inodos , como ext2 , ext3 y reiserFS .
  • Bases de datos con campos de tiempo de 32 bits.
  • Lenguajes de consulta de bases de datos (como SQL ) que tienen UNIX_TIMESTAMP()comandos similares a .
  • Muchos dispositivos Android de 32 bits con Android 4 o anterior, incluidos ZTE Blade , [ 8 ] Google Nexus 7 [ 9 ] y tabletas Android Toshiba de 2012. [ 10 ]
  • Los Mac PowerPC de la era OS X tendrán su reloj del sistema atascado en el tiempo de rollover a partir de Mac OS X Tiger . [ 11 ]
  • Los dispositivos iOS de 32 bits, a partir del iPhone 5 con iOS 9 aproximadamente, no podrán desbloquearse ni entrar en modo de carga de forma consistente, y el reloj de la pantalla de bloqueo no se mostrará. [ 12 ]
  • A partir de la versión 22H2 de Windows 10 , si un dispositivo x86 (32 bits) no se ha encendido en el momento del cambio de fecha, pero se inicia después del cambio, el reloj del sistema puede avanzar hasta el 12 de abril de 2160, y las opciones de fecha en el menú de configuración principal de Windows 10 no muestran ningún número seleccionable. [ 13 ]
  • El software compilado con Visual Studio tiene el _gmtime32formato (que sirve como una asignación de time_tla versión de 32 bits de ) se reinicia el 19 de enero de 2038 a las 00:00:00. Se sabe que el software compilado con versiones anteriores a 2005 de Visual Studio se _gmtimecorresponde con _gmtime32, y la correspondencia se puede forzar al compilar con versiones de 32 bits de Visual Studio hasta Visual Studio 2019 especificando _USE_32BIT_TIME_T. [ 14 ]

Sistemas embebidos

Los sistemas embebidos que utilizan fechas para cálculos o registros de diagnóstico son los más propensos a verse afectados por el problema del año 2038. [ 1 ] A pesar de la actualización generacional moderna de 18 a 24 meses en la tecnología de sistemas informáticos , los sistemas embebidos están diseñados para durar toda la vida útil de la máquina en la que forman parte. Es posible que algunos de estos sistemas sigan en uso en 2038. Puede resultar difícil o, en algunos casos, imposible actualizar el software que ejecuta estos sistemas, lo que en última instancia requerirá su reemplazo si se quieren corregir las limitaciones de 32 bits.

Muchos sistemas de transporte, desde el vuelo hasta los automóviles, utilizan ampliamente sistemas integrados. En los sistemas automotrices, esto puede incluir el sistema de frenos antibloqueo (ABS), el control electrónico de estabilidad (ESC/ESP), el control de tracción (TCS) y la tracción automática en las cuatro ruedas ; las aeronaves pueden utilizar sistemas de guía inercial y receptores GPS . [ c ]

Otro uso importante de los sistemas embebidos se encuentra en los dispositivos de comunicación, incluidos los teléfonos móviles y los electrodomésticos con conexión a Internet, por ejemplo, enrutadores , puntos de acceso inalámbricos , cámaras IP , que dependen del almacenamiento de una hora y fecha precisas y que cada vez se basan más en sistemas operativos tipo Unix.

Sin embargo, esto no implica que todos los sistemas embebidos sufrirán el problema del año 2038, ya que muchos de ellos no requieren acceso a fechas. Para aquellos que sí lo requieren, los sistemas que solo registran la diferencia entre fechas y horas, y no fechas y horas absolutas, no experimentarán un problema grave debido a la naturaleza del cálculo. Este es el problema para los diagnósticos automotrices basados ​​en estándares legislados como CARB ( Junta de Recursos del Aire de California ). [ 15 ]

Problemas tempranos

En mayo de 2006, surgieron informes sobre una manifestación temprana del problema del año 2038 en el software AOLserver . El software se diseñó con una solución provisional para gestionar una solicitud de base de datos que "nunca" debería agotar el tiempo de espera. En lugar de gestionar específicamente este caso especial, el diseño inicial simplemente especificaba una fecha de caducidad arbitraria en el futuro con una configuración predeterminada que indicaba que las solicitudes debían agotar el tiempo de espera después de un máximo de mil millones de segundos. Sin embargo, mil millones de segundos antes de la fecha límite de 2038 es la 01:27:28  UTC del 13 de mayo de 2006, por lo que las solicitudes enviadas después de esta hora darían como resultado una fecha de caducidad que superaba el límite. Esto provocaba que los cálculos de tiempo de espera se desbordaran y devolvieran fechas que en realidad eran pasadas, lo que causaba que el software fallara. Cuando se descubrió el problema, los operadores de AOLServer tuvieron que editar el archivo de configuración y establecer el tiempo de espera en un valor inferior. [ 4 ] [ 5 ]

Muchos tipos de certificados CA autofirmados generados en sistemas de 32 bits pueden tener fechas de vencimiento muy largas que superan el punto de renovación, lo que hará que no funcionen correctamente, afectando las verificaciones HTTPS en servicios (por ejemplo, VPN ) y sitios que los utilizan. [ 16 ]

Las funciones antimalware MS Filtering Engine Update de las instalaciones de Microsoft Exchange Server dejaron de funcionar el 1 de enero de 2022 tras una actualización. Estas funciones asignaban los números UpdateVersion procesados ​​(que utilizaban un formato YY-MM-DD-n de 9 o 10 dígitos) a los números de marca de tiempo Unix, a pesar de que sus horas eran muy diferentes. Por lo tanto, cuando el motor recibió la actualización 220101001 (22-01-01 v001), que interpretó como 2201010001 con un cero adicional cerca del final, intentó asignarla al número de tiempo Unix de 32 bits y falló debido a que era mayor que 2147483647. [ 17 ] Los servidores Exchange afectados dejaron de funcionar a menos que desactivaran las funciones antimalware, y se publicó una solución automatizada el 5 de enero de 2022.

En Oracle Access Management versión 10.1.4.3 para Windows, el componente Identity Console establece una cookie que contiene preferencias de interfaz de usuario con una caducidad de 500.000.000  segundos en el futuro (aproximadamente 15  años y 312  días). A partir de las 02:20:48  UTC del 17  de marzo de 2022, esta fecha de caducidad es posterior al 19  de enero de 2038, por lo que genera una excepción para ciertas actividades de búsqueda, ya que la gmtime_r()llamada no puede convertir el número proporcionado a una fecha para escribir en la cookie. [ 18 ]

Soluciones

No existe una solución universal para el problema del año 2038. Por ejemplo, en el lenguaje C , cualquier cambio en la definición del time_ttipo de datos resultaría en problemas de compatibilidad de código en cualquier aplicación en la que las representaciones de fecha y hora dependan de la naturaleza del time_tentero con signo de 32 bits. Cambiar time_ta un entero sin signo de 32 bits, lo que extendería el rango a 2106 [ 19 ] (específicamente, 06:28:15 UTC del domingo 7 de febrero de 2106), afectaría negativamente a los programas que almacenan, recuperan o manipulan fechas anteriores a 1970, ya que dichas fechas se representan con números negativos. Aumentar el tamaño del time_ttipo a 64 bits en un sistema existente causaría cambios incompatibles en el diseño de las estructuras y la interfaz binaria de las funciones.

La mayoría de los sistemas operativos diseñados para ejecutarse en hardware de 64 bits ya utilizan time_tenteros de 64 bits con signo . El uso de un valor de 64 bits con signo introduce una nueva fecha de reinicio que es más de veinte veces mayor que la edad estimada del universo : aproximadamente 292  mil millones de años a partir de ahora. [ 20 ] Sin embargo, el software en sistemas operativos de 64 bits aún puede causar problemas al usar enteros de 32 bits para manejar marcas de tiempo. [ 21 ] La capacidad de realizar cálculos con fechas está limitada por el hecho de que tm_yearutiliza un valor entero de 32 bits con signo que comienza en 1900 para el año. Esto limita el año a un máximo de 2.147.485.547 (2.147.483.647 + 1900). [ 22 ]

Se han hecho propuestas alternativas (algunas de las cuales ya están en uso), como almacenar milisegundos o microsegundos desde una época (normalmente el 1 de enero de 1970 o el 1 de enero de 2000) en un entero con signo de 64 bits, proporcionando un rango mínimo de 292.000 años con resolución de microsegundos. [ 23 ] [ 24 ] En particular, el uso de enteros con signo de 64 bits por parte de Java y JavaScript para representar marcas de tiempo absolutas como "milisegundos desde el 1 de enero de 1970" funcionará correctamente durante los próximos 292 millones de años . Otras propuestas para nuevas representaciones de tiempo proporcionan diferentes precisiones, rangos y tamaños (casi siempre más amplios que 32 bits), además de resolver otros problemas relacionados, como el manejo de segundos intercalares . En particular, TAI64 [ 25 ] es una implementación del estándar de Tiempo Atómico Internacional (TAI), el estándar internacional actual de tiempo real para definir un segundo y un marco de referencia.

Soluciones implementadas

  • A partir de la versión 1.9.2 de Ruby (lanzada el 18 de agosto de 2010), se corrige el error con el año 2038, [ 26 ] almacenando el tiempo en un entero con signo de 64 bits en sistemas con 32 bits time_t. [ 27 ]
  • A partir de la versión 6.0 de NetBSD (lanzada en octubre de 2012), el sistema operativo NetBSD utiliza una arquitectura de 64 bits time_ttanto para arquitecturas de 32 bits como de 64 bits. Las aplicaciones compiladas para una versión anterior de NetBSD de 32 bits time_tson compatibles mediante una capa de compatibilidad binaria, pero dichas aplicaciones antiguas seguirán sufriendo el problema Y2038. [ 28 ]
  • OpenBSD, desde la versión 5.5, lanzada en mayo de 2014, también utiliza una arquitectura de 64 bits time_ttanto para arquitecturas de 32 bits como de 64 bits. A diferencia de NetBSD , no existe una capa de compatibilidad binaria. Por lo tanto, las aplicaciones que esperan una arquitectura de 32 bits time_ty las que utilizan algo diferente time_tpara almacenar valores de tiempo pueden fallar. [ 29 ]
  • Linux originalmente usaba 64 bits solo para arquitecturas de 64 bits; la ABItime_t pura de 32 bits no se modificó debido a la compatibilidad con versiones anteriores. [ 30 ] A partir de la versión 5.6 de 2020, también se admite 64 bits en arquitecturas de 32 bits. Esto se hizo principalmente para los sistemas Linux embebidos . [ 31 ]time_t
  • La biblioteca GNU C, desde la versión 2.34 (lanzada en agosto de 2021), añadió soporte para usar 64 bits time_ten plataformas de 32 bits con las versiones de Linux adecuadas. Este soporte se puede activar definiendo una macro de preprocesador _TIME_BITSal 64compilar el código fuente. [ 32 ]
  • FreeBSD utiliza 64 bits time_tpara todas las arquitecturas de 32 y 64 bits, excepto para i386 de 32 bits, que utiliza 32 bits con signo time_ten su lugar. [ 33 ]
  • La ABI x32 para Linux (que define un entorno para programas con direcciones de 32 bits, pero que ejecutan el procesador en modo de 64 bits) utiliza 64 bits time_t. Dado que era un entorno nuevo, no había necesidad de precauciones especiales de compatibilidad. [ 30 ]
  • El sistema de archivos de red versión 4 ha definido sus campos de tiempo como struct nfstime4 {int64_t seconds; uint32_t nseconds;}desde diciembre de 2000. [ 34 ] La versión 3 admite valores de 32 bits sin signo como struct nfstime3 {uint32 seconds; uint32 nseconds;};. [ 35 ] Los valores mayores que cero para el campo de segundos indican fechas posteriores a la hora 0, 1 de enero de 1970. Los valores menores que cero para el campo de segundos indican fechas anteriores a la hora 0, 1 de enero de 1970. En ambos casos, el campo nseconds (nanosegundos) debe agregarse al campo de segundos para la representación final del tiempo.
  • El sistema de archivos ext4 , cuando se utiliza con tamaños de inodo mayores de 128 bytes, tiene un campo adicional de 32 bits por marca de tiempo, de los cuales 30 bits se utilizan para la parte de nanosegundos de la marca de tiempo, y los otros 2 bits se utilizan para extender el rango de la marca de tiempo hasta el año 2446. [ 36 ]
  • El sistema de archivos XFS , a partir de Linux 5.10, tiene una función opcional de "marcas de tiempo grandes" que extiende el rango de marcas de tiempo hasta el año 2486. [ 37 ]
  • Si bien las API nativas de OpenVMS pueden admitir marcas de tiempo hasta el 31 de julio de 31086, [ 38 ] la biblioteca de tiempo de ejecución de C (CRTL) utiliza enteros de 32 bits para time_t. [ 39 ] Como parte del trabajo de cumplimiento del efecto 2000 que se llevó a cabo en 1998, la CRTL se modificó para usar enteros sin signo de 32 bits para representar el tiempo; extendiendo el rango de time_thasta el 7 de febrero de 2106. [ 40 ]
  • A partir de MySQL 8.0.28, publicado en enero de 2022, las funciones FROM_UNIXTIME(), UNIX_TIMESTAMP(), y CONVERT_TZ()manejan valores de 64 bits en plataformas que los admiten. Esto incluye versiones de 64 bits de Linux, macOS y Windows. [ 41 ] [ 42 ] En versiones anteriores, las funciones integradas como UNIX_TIMESTAMP()devolverán 0 después de las 03:14:07 UTC del 19 de enero de 2038. [ 43 ]
  • A partir de MariaDB 11.5.1, lanzado en mayo de 2024, el tipo de datos TIMESTAMPy las funciones FROM_UNIXTIME(), UNIX_TIMESTAMP(), y CONVERT_TZ()manejan valores de 32 bits sin signo en versiones de 64 bits de Linux, macOS y Windows. [ 44 ] Esto extendió el rango hasta 2106-02-07 06:28:15 y permitió a los usuarios almacenar dichos valores de marca de tiempo en tablas sin cambiar el diseño de almacenamiento y, por lo tanto, mantener una compatibilidad total con los datos de usuario existentes.
  • A partir de Visual C++ 2005, la CRT utiliza 64 bits a menos que se defina time_tla macro del preprocesador. [ 45 ] Sin embargo, la propia API de Windows no se ve afectada por el error del año 2038, ya que Windows realiza internamente un seguimiento del tiempo como el número de intervalos de 100 nanosegundos desde el 1 de enero de 1601 en un entero con signo de 64 bits, que no se desbordará hasta el año 30.828 . [ 46 ]_USE_32BIT_TIME_T
  • El error que provocaba que el reloj del sistema se quedara bloqueado al pasar el cursor sobre el botón rojo en OS X se solucionó a partir de Mac OS X El Capitan .
  • DOSBox-X eliminó una dependencia de la macro Int32x32To64 para el cálculo del tiempo en la versión 2025.02.01. [ 47 ]
  • Para los dispositivos Windows cuyos relojes se han adelantado, existen varias herramientas de software para editar la configuración del sistema o para sincronizarlos con servidores de hora que pueden mitigar cualquier efecto.
  • Las guías de sintaxis de Microsoft para Visual Studio han desaconsejado el uso de _USE_32BIT_TIME_T, y no se ha permitido al compilar con versiones de 64 bits de Visual Studio. [ 14 ]
  • A pesar de la antigüedad de la versión de Oracle Access Manager en cuestión (18 de junio de 2009), Oracle publicó el parche 33983548 el 6  de abril de 2022. No se tiene constancia de que las versiones más recientes de Oracle Access Manager se vean afectadas por este problema.

Véase también

Notas

  1. Salvo que se especifique lo contrario, todos los números proporcionados en este artículo se han derivado utilizando el complemento a dos para la aritmética de enteros con signo.
  2. 2.147.483.647 es un doble primo de Mersenne
  3. El GPS sufre su propio problema de desbordamiento del contador de tiempo conocido como GPS Week Number Rollover .

Referencias

  1. 1 2 Gibbs, Samuel (17 de diciembre de 2014). "¿Es el problema del año 2038 el nuevo error Y2K?" . The Guardian . Archivado del original el 25 de enero de 2022 . Recuperado el 11 de octubre de 2018 .
  2. Bergmann, Arnd (6 de febrero de 2020). "El fin de una era" . Linaro. Archivado del original el 7 de febrero de 2020. Recuperado el 13 de septiembre de 2020 .
  3. Wagenseil, Paul (28 de julio de 2017). "Una 'época apocalíptica' digital podría paralizar el mundo" . Tom's Guide . Archivado del original el 29 de noviembre de 2021. Consultado el 13 de septiembre de 2020 .
  4. 1 2 "El futuro está por delante" . 28 de junio de 2006. Archivado del original el 28 de noviembre de 2006. Recuperado el 19 de noviembre de 2006 .
  5. 1 2 Problema extraño de "fuga de memoria" en AOLserver 3.4.2/3.x Archivado el 4 de enero de 2010 en Wayback Machine el 12 de mayo de 2006
  6. 2 63 segundos ÷ 60 segundos/minuto ÷ 60 minutos/hora ÷ 24 horas/día ÷ (146097 días/400 años =) 365,2425 días/año gregoriano [≈ 292,277 mil millones (años gregorianos)] ÷ 13,79 mil millones de años ≈ 21,19 veces la edad estimada del universo después de la medianoche UTC del 1 de enero de 1970, sin tener en cuenta los segundos intercalares .
  7. Diomidis Spinellis (2006). Calidad del código: la perspectiva del código abierto . Serie Desarrollo de software eficaz en Safari Books Online ( edición ilustrada). Adobe Press . pág. 49. ISBN   978-0-321-16607-4.
  8. "El ZTE Blade con Android 2.2 tiene 2038 problemas" . Archivado del original el 19 de mayo de 2022. Consultado el 20 de noviembre de 2018 .
  9. Larry Seltzer (19 de enero de 2013). "25 años a partir de hoy: un tiempo para los bichos" . InformationWeek . Archivado del original el 26 de agosto de 2025. Recuperado el 16 de agosto de 2025 .
  10. "Toshiba TOSHIBA AT300" (PDF) . 2012. Archivado (PDF) del original el 4 de septiembre de 2025. Recuperado el 16 de agosto de 2025 .
  11. "El problema del año 2038" . Interconectado. Archivado del original el 16 de julio de 2014. Consultado el 16 de agosto de 2025 .
  12. Ternary (10 de diciembre de 2015). "El apocalipsis del iPhone: 19 de enero de 2038" . MacRumors . Consultado el 17 de agosto de 2025 .
  13. Sayan Sen (6 de marzo de 2024). "¿Recuerdas el efecto 2000? Una aplicación de Windows 95, 98 y 2000 sorprendentemente resiste el supererror Y2K38" . Neowin . Archivado del original el 3 de septiembre de 2025. Consultado el 19 de agosto de 2025 .
  14. 1 2 "gmtime, _gmtime32, _gmtime64" . Microsoft Learn. 2 de marzo de 2024. Archivado del original el 8 de diciembre de 2024. Recuperado el 11 de septiembre de 2025 .
  15. "Métodos/Procedimientos de prueba de ARB" . ARB.ca.gov . Junta de Recursos del Aire de California . Archivado del original el 18 de noviembre de 2016. Consultado el 12 de septiembre de 2013 .
  16. Thomas Claburn (9 de febrero de 2025). «Una curiosa historia de VPNs defectuosas, el año 2038 y certificados que caducaron hace 100 años» . The Register . Archivado del original el 1 de agosto de 2025. Consultado el 17 de agosto de 2025 .
  17. Dean Howell (1 de enero de 2022). "Error del año 2022: Microsoft comienza el año nuevo dejando inoperativos los servidores de Exchange en todo el mundo" . Neowin . Archivado del original el 24 de agosto de 2025. Consultado el 19 de agosto de 2025 .
  18. "Oracle Access Manager" . Comunidades de Oracle . Oracle Corporation. 24 de marzo de 2022. Consultado el 25 de febrero de 2023 .
  19. "BORRADOR: Diseño de prueba Y2038" . Archivado del original el 21 de septiembre de 2019. Consultado el 25 de mayo de 2024 .
  20. Endrestøl, Trond (10 de marzo de 2015). "¿Cuándo termina realmente el time_t de Unix de 64 bits?" . Ximalas . Archivado del original el 23 de septiembre de 2022 . Recuperado el 24 de septiembre de 2022 .
  21. "Hoy es el día de conmemoración del Y2K38 T-13" . 19 de enero de 2025.{{cite web}}: CS1 mantenimiento: estado de la URL ( enlace )
  22. Felts, Bob (17 de abril de 2010). "El fin de los tiempos" . Stablecross.com . Archivado del original el 11 de octubre de 2012. Recuperado el 19 de marzo de 2012 .
  23. "Tiempo de Unununium" . Archivado del original el 8 de abril de 2006. Consultado el 19 de noviembre de 2006 .
  24. Sun Microsystems. "Documentación de la API de Java para System.currentTimeMillis()" . Archivado del original el 30 de septiembre de 2017. Consultado el 29 de septiembre de 2017 .
  25. "TAI64" . Archivado del original el 26 de septiembre de 2012. Consultado el 4 de septiembre de 2012 .
  26. "Se lanza Ruby 1.9.2" . 18 de agosto de 2010. Archivado del original el 8 de abril de 2022. Consultado el 1 de abril de 2022 .
  27. "time.c: usar aritmética de 64 bits incluso en plataformas con VALOR de 32 bits" . GitHub . Archivado del original el 3 de noviembre de 2023. Recuperado el 3 de noviembre de 2023 .
  28. "Anuncio de NetBSD 6.0" . 17 de octubre de 2012. Archivado del original el 15 de enero de 2016. Consultado el 18 de enero de 2016 .
  29. "OpenBSD 5.5 lanzado (1 de mayo de 2014)" . 1 de mayo de 2014. Archivado del original el 22 de diciembre de 2015. Consultado el 18 de enero de 2016 .
  30. 1 2 Jonathan Corbet (14 de agosto de 2013). "Reflexionando sobre 2038" . LWN.net . Archivado del original el 4 de marzo de 2016. Recuperado el 9 de marzo de 2016 .
  31. "LKML: Arnd Bergmann: [ GIT PULL ] y2038: cambios en el núcleo, el controlador y el sistema de archivos" . lkml.org . Archivado del original el 14 de febrero de 2020. Consultado el 30 de enero de 2020 .
  32. O'Donell, Carlos (2 de agosto de 2021). "La versión 2.34 de la biblioteca GNU C ya está disponible" . Sourceware . Archivado del original el 30 de abril de 2024. Recuperado el 30 de abril de 2024 .
  33. "arch" . www.freebsd.org . Archivado del original el 26 de septiembre de 2018. Consultado el 26 de septiembre de 2018 .
  34. Haynes, Thomas; Noveck, David, eds. (marzo de 2015). "Tipos de datos estructurados" . Protocolo del sistema de archivos de red (NFS) versión 4. IETF . sec. 2.2. doi : 10.17487/RFC7530 . RFC 7530 . 
  35. Staubach, Peter; Pawlowski, Brian; Callaghan, Brent (junio de 1995). "Especificación del protocolo NFS versión 3" . Archivado del original el 15 de mayo de 2024. Recuperado el 25 de mayo de 2024 .
  36. "Estructuras de datos y algoritmos ext4" . Archivado del original el 13 de septiembre de 2022. Consultado el 13 de septiembre de 2022 .
  37. Michael Larabel (15 de octubre de 2020). "El sistema de archivos XFS con Linux 5.10 pospone el problema del año 2038 al año 2486" . Phoronix . Archivado del original el 13 de septiembre de 2022. Consultado el 13 de septiembre de 2022 .
  38. "¿Por qué el miércoles 17 de noviembre de 1858 es la hora base para OpenVMS (VAX VMS)?" . Universidad de Stanford . 24 de julio de 1997. Archivado del original el 24 de julio de 1997 . Consultado el 8 de enero de 2020 .
  39. "Manual de referencia de la biblioteca de tiempo de ejecución VSI C para sistemas OpenVMS" (PDF) . VSI. Noviembre de 2020. Archivado del original (PDF) el 17 de abril de 2021. Consultado el 17 de abril de 2021 .
  40. "OpenVMS y el año 2038" . HP. Archivado del original el 17 de abril de 2021. Recuperado el 17 de abril de 2021 .
  41. "Novedades de MySQL 8.0" . dev.mysql.com . Archivado del original el 13 de noviembre de 2021. Consultado el 13 de noviembre de 2021 .
  42. "Cambios en MySQL 8.0.28 (18-01-2022, Disponibilidad general)" . dev.mysql.com . Archivado del original el 8 de diciembre de 2023. Consultado el 14 de mayo de 2024 .
  43. "Errores de MySQL: #12654: Las funciones de MySQL no admiten marcas de tiempo Unix de 64 bits" . bugs.mysql.com . Archivado del original el 29 de marzo de 2017. Consultado el 28 de marzo de 2017 .
  44. "Notas de la versión 11.5.1 de MariaDB" . Base de conocimientos de MariaDB . Archivado del original el 7 de septiembre de 2024. Consultado el 6 de septiembre de 2024 .
  45. "Historial de cambios de Microsoft C/C++ 2003 - 2015" . learn.microsoft.com . 25 de mayo de 2023. Consultado el 13 de agosto de 2024 .
  46. "Ya era hora: aplicaciones Win32" . learn.microsoft.com . 7 de enero de 2021. Consultado el 13 de agosto de 2024 .
  47. Jon Campbell. "Notas de la versión DOSBox-X 2025.02.01" . Archivado del original el 23 de abril de 2025. Consultado el 19 de agosto de 2025 .
  • Wiki de glibc sobre el diseño de prueba Y2038
  • Entrada en Cómo funcionan las cosas
  • Preguntas frecuentes sobre el Proyecto 2038
  • Fechas críticas y significativas 2038 Archivado el 7 de noviembre de 2020 en Wayback Machine
  • Un reemplazo seguro hasta 2038 para time.h en sistemas de 32 bits.
  • "Resolviendo el problema del año 2038 en el kernel de Linux" .
  • Baraniuk, Chris (5 de mayo de 2015). "El fallo numérico que puede provocar una catástrofe" . BBC Future .
  • Clewett, James. "2.147.483.647 – El fin del tiempo [ Unix ] " . Numberphile . Brady Haran . Archivado del original el 22 de mayo de 2017. Recuperado el 7 de abril de 2013 .