En informática , las limitaciones de los tipos de datos y los errores de software pueden provocar errores en el cálculo o visualización de la fecha y la hora . Estas son manifestaciones más comunes de desbordamiento aritmético , pero también pueden ser el resultado de otros problemas. La consecuencia más conocida de este tipo es el problema Y2K , pero existen muchas otras fechas u momentos importantes que han causado o causarán problemas dependiendo de diversas deficiencias de programación.
El 4 de enero de 1975, el campo de 12 bits que se había utilizado para las fechas en los sistemas operativos DECsystem-10 se desbordó. Hubo numerosos problemas y fallas relacionadas con este error mientras se desarrollaba un formato alternativo. [1]
El sistema operativo OS/8 de Digital Equipment Corporation para la computadora PDP-8 utilizó sólo tres bits para el año, lo que representa los años 1970 a 1977. [2]
Esto se reconoció cuando se desarrolló el sistema operativo COS-310 y las fechas se registraron de manera diferente. [3]
Varios juegos de Sierra Entertainment lanzados para Classic Mac OS comenzaron a congelarse cuando se ejecutaban el 18 de septiembre de 1993. Un problema en la versión para Mac de Sierra's Creative Interpreter (Mac SCI) causaba que el juego se "bloqueara" al intentar manejar un retraso. debido a un problema relacionado con un desbordamiento. Mac SCI intentaría utilizar la fecha para determinar cuánto debería durar un retraso obteniendo la hora actual en segundos desde el 1 de enero de 1904, la época de Macintosh, y dividiéndola por 12 horas. La división fue procesada por el Motorola 68000 y no ocurriría si se detectara un desbordamiento debido a la división, pero el Mac SCI continuaría independientemente como si la división hubiera ocurrido, lo que eventualmente resultaría en un retraso de un segundo que se trataría como un retraso. durante 18 horas y así sucesivamente. Sierra lanzó un parche llamado MCDATE que resolvió el problema durante casi 14 años. [4] [5]
El reloj del dominio/sistema operativo , que se basa en el número de unidades de 4 microsegundos que se han producido desde el 1 de enero de 1980, superó los 47 bits el 2 de noviembre de 1997, lo que dejó inutilizables los sistemas sin parches. [6]
En los últimos meses antes del año 2000, ocurrieron otros dos hitos relacionados con fechas que recibieron menos publicidad que el entonces inminente problema del año 2000.
Las fechas GPS se expresan como un número de semana y un número de día de la semana, y el número de semana se transmite como un valor de diez bits . Esto significa que cada 1.024 semanas (aproximadamente 19,6 años) después del domingo 6 de enero de 1980 (la época del GPS ), la fecha se reinicia nuevamente a esa fecha; Esto sucedió por primera vez a las 23:59:47 del 21 de agosto de 1999, [7] la segunda vez a las 23:59:42 UTC del 6 de abril de 2019, y volverá a suceder el 20 de noviembre de 2038. [8] Para abordar este problema Preocupación, los mensajes de navegación GPS modernizados utilizan un campo de 13 bits, que sólo se repite cada 8.192 semanas (157 años), y no volverá a cero hasta el año 2137. [9]
En muchos programas o conjuntos de datos, "9/9/99" se usaba como un valor falso para indicar una fecha no resuelta o como un terminador para indicar que no había más datos en el conjunto. Esto generó problemas cuando llegó la fecha real que esto representa, el 9 de septiembre de 1999. [7]
Los problemas posteriores causados por ciertas soluciones temporales al problema del año 2000 surgirán en varios momentos del siglo XXI. Algunos programas se adaptaron al año 2000 al continuar utilizando años de dos dígitos, pero eligiendo un año arbitrario antes del cual esos años se interpretan como 20 xx y después del cual se interpretan como 19 xx . [10]
Por ejemplo, es posible que se haya modificado un programa para que trate los valores de años de dos dígitos 00–68 como si se refirieran a 2000 hasta 2068, y los valores 69–99 como si se refirieran a 1969 hasta 1999. [11] Un programa de este tipo no podrá para abordar correctamente los años posteriores a 2068.
Para las aplicaciones necesarias para calcular el año de nacimiento (u otro año anterior), dicho algoritmo se ha utilizado durante mucho tiempo para superar el problema del año 1900 , pero no ha podido reconocer a las personas mayores de 100 años .
Los sistemas que utilizaron una cadena de nueve dígitos para registrar el tiempo en segundos desde la época Unix tuvieron problemas para informar tiempos más allá de la milmillonésima de segundo después de la época el 9 de septiembre de 2001 a las 01:46:40 (el "milenio"). Los problemas no fueron generalizados. [12]
Los juegos de Sierra Entertainment para Mac OS clásico que fueron parcheados con el programa MCDATE o lanzados posteriormente con el parche incorporado comenzarían a congelarse el 28 de mayo de 2007. Al igual que con el problema del año 1993, esto se debió a un problema en Mac SCI cuando intentar utilizar la fecha para determinar cuánto tiempo debe durar un retraso. Los programas con el parche MCDATE se congelan porque Mac SCI toma la cantidad actual de segundos desde la época de Macintosh del 1 de enero de 1904, resta 432.000.000 de segundos y luego los divide por 12 horas a través del Motorola 68000, para luego determinar cuánto deben durar los retrasos. . El 28 de mayo de 2007, el Motorola 68000 nuevamente no se divide debido a una protección contra desbordamiento, que Mac SCI ignora. [4]
Algunos sistemas tuvieron problemas una vez que el año pasó a 2010. Algunos medios lo denominaron como el problema "Y2K+10" o "Y2.01k". [13]
La principal fuente de problemas fue la confusión entre la codificación de números hexadecimales y las codificaciones de números BCD . Los números del 0 al 9 están codificados tanto en hexadecimal como en BCD como 00 16 a 09 16 . Pero el número decimal 10 está codificado en hexadecimal como 0A 16 y en BCD como 10 16 . Así, un BCD 10 16 interpretado como codificación hexadecimal representa erróneamente el número decimal 16.
Por ejemplo, el protocolo SMS utiliza codificación BCD para las fechas, por lo que algunos software de teléfonos móviles informaron incorrectamente las fechas de los mensajes como 2016 en lugar de 2010. Windows Mobile fue el primer software afectado por este problema; en algunos casos, WM6 cambió la fecha de cualquier mensaje SMS entrante enviado después del 1 de enero de 2010, del año 2010 al 2016. [14] [15]
Otros sistemas afectados incluyen terminales EFTPOS , [16] y la PlayStation 3 (excepto el modelo Slim). [17]
La PlayStation 3 de Sony trató incorrectamente el año 2010 como un año bisiesto , por lo que el inexistente 29 de febrero de 2010, se mostró el 1 de marzo de 2010, provocando un error en el programa . [18]
El problema más importante se produjo en Alemania, donde más de 20 millones de tarjetas bancarias quedaron inutilizables, y en Citibank Bélgica, cuyos chips de identificación de clientes Digipass dejaron de funcionar. [19]
Taiwán utiliza oficialmente el calendario Minguo , que considera el año gregoriano 1912 como su año 1. Así, el año gregoriano 2011 es el año 100 de la República de China, su primer año de 3 dígitos. [20]
La sonda espacial Deep Impact perdió comunicación con la Tierra el 11 de agosto de 2013 debido a un problema de etiquetado de tiempo; la fecha se almacenó como un entero de 32 bits sin signo contando el número de décimas de segundo desde el 1 de enero de 2000. [21]
En 2019, se produjo la segunda transferencia del número de semana del GPS .
El 30 de abril de 2019, el emperador Akihito de Japón abdicó en favor de su hijo Naruhito . Como en Japón los años se denominan tradicionalmente mediante nombres de era que corresponden al reinado de cada emperador, esto dio lugar a un nuevo nombre de era, Reiwa (令和) , tras el ascenso de Naruhito al trono al día siguiente. Debido a que el emperador anterior, Hirohito , murió el 7 de enero de 1989, y el reinado de Akihito correspondió principalmente con el aumento en el uso de las computadoras, la mayor parte del software no había sido probado para garantizar el comportamiento correcto en un cambio de era, mientras que las pruebas se complicaron aún más por el hecho de que El nombre de la nueva era no se reveló hasta el 1 de abril de 2019. Por lo tanto, se esperaban errores del software que no anticipaba una nueva era.
Los videojuegos WWE 2K20 y Star Wars Jedi: Fallen Order fallaron el 1 de enero de 2020, cuando terminó el año. Los fallos sólo podían evitarse reiniciando el año 2019 hasta que se lanzara un parche. [22] [23] Además, Crystal Reports 8.5 no generaría informes específicos a partir de 2020. [24]
Los parquímetros de Parkeon en la ciudad de Nueva York y otras ubicaciones no podían aceptar tarjetas de crédito como forma de pago a partir de 2020. Se implementó una solución alternativa, pero requería que cada parquímetro se actualizara individualmente. En Nueva York, no se esperaba que los contadores estuvieran reparados hasta el 9 de enero. [25] [26]
En Polonia, 5.000 cajas registradoras dejaron de imprimir la fecha correctamente. [27]
Los relojes deportivos inteligentes Suunto mostraron un error al calcular los días de la semana que se presentaban con un paso +2 (por ejemplo, VIE en lugar de MIÉ, SÁB en lugar de JUE). Para los relojes modelo Suunto Spartan, el error se solucionó con la versión de firmware 2.8.32. [28]
El panel de control en las versiones 6, 7 y 8 de Classic Mac OS solo permite establecer la fecha hasta el 31 de diciembre de 2019, aunque el sistema puede continuar avanzando el tiempo más allá de esa fecha. [29] [30]
La primera versión de Microsoft Schedule+ incluida con la versión 3.0 del cliente de correo electrónico Microsoft Mail se negará a funcionar con años superiores a 2020 o posteriores, debido a que el programa fue diseñado para funcionar dentro de un período de 100 años que va desde 1920. a 2019. Como resultado, la fecha solo puede fijarse hasta el 31 de diciembre de 2019. [31]
Los usuarios de Samsung informaron que los teléfonos que funcionan con la última actualización de One UI 3.0 o Android 11 perdieron el acceso a la batería y a las estadísticas de carga a partir de 2021. Los dispositivos afectados no informaron estadísticas de uso, por lo que esas secciones quedaron en blanco. [32] [33]
Las fechas almacenadas en el formato aammddHHMM convertidas a un entero de 32 bits con signo se desbordaron el 1 de enero de 2022, como 2 31 =2147483648. Notablemente afectados fueron los números de actualización de los componentes de escaneo de malware de Microsoft Exchange , que parecen usarse para una verificación matemática para determinar la última actualización. [34] [35]
Los automóviles Honda y Acura fabricados entre 2004 y 2012 que contenían sistemas de navegación GPS mostraban incorrectamente el año 2002. Este problema se debía a un desbordamiento en la época del GPS. [36] [37] El problema se resolvió el 17 de agosto de 2022. [38]
Los lectores de tarjetas de pago en los surtidores de gasolina en Nueva Zelanda no pudieron manejar el año bisiesto y no pudieron dispensar gasolina adecuadamente. [39]
Los videojuegos EA Sports WRC y Theatrhythm Final Bar Line también sufrieron problemas relacionados con el año bisiesto, el primero falló al intentar cargar el juego y el segundo afirmó que los datos guardados estaban dañados. Ambos juegos tuvieron que configurarse para el día siguiente, 1 de marzo de 2024, para que funcionaran correctamente. [40] [41] [42]
En Japón, algunos sistemas informáticos más antiguos que utilizan el calendario japonés y que no se han actualizado todavía cuentan los años según la era Shōwa . El año 2025 corresponde en estos sistemas al Shōwa 100, lo que puede causar problemas si el software asume dos dígitos para el año. [43]
Algunos sistemas almacenan su año como un desplazamiento de un solo byte desde 1900, lo que da un rango de 255 (8 bits) y permite representar de forma segura fechas hasta 2155. Sin embargo, no todos los sistemas utilizan un byte sin firmar : algunos han sido codificados por error con un byte firmado que sólo permite un rango de 127 años, lo que significa que el campo de fecha en el software será incorrecto después de 2027 y puede provocar un comportamiento impredecible. Esto afecta a varias piezas de software de disco óptico que funcionan con el formato ISO 9660 . [44]
A finales de la década de 1970, en los sistemas Data General Nova y Eclipse, World Computer Corporation (que realiza aplicaciones para cooperativas de crédito) creó un formato de fecha con un campo de fecha de 16 bits para 128 años (7 bits – nota 1900+128=2028), 12 meses (4 bits) y 31 días (5 bits). Esto permitió que las fechas fueran directamente comparables utilizando funciones sin firmar. Algunos sistemas, incluido el HP 3000 , todavía utilizan este formato, aunque consultores externos han desarrollado un parche. [45]
Palm OS utiliza tanto enteros con signo con la época de 1970 como enteros sin signo con la época de 1904, para diferentes funciones del sistema, [46] como el reloj del sistema y las fechas de los archivos (consulte el formato PDB ). Si bien esto debería hacer que Palm OS sea susceptible al problema 2038, Palm OS también utiliza un campo de 7 bits para almacenar el valor del año, con una época diferente a partir de 1904, lo que da como resultado un año máximo de 2031 (1904+127). [47]
El protocolo de tiempo de red tiene un problema de desbordamiento relacionado con el problema del año 2038 , que se manifiesta a las 06:28:16 UTC del 7 de febrero de 2036, en lugar de 2038. Las marcas de tiempo de 64 bits utilizadas por NTP constan de una parte de 32 bits para segundos y una parte de 32 bits para fracciones de segundo, lo que le da a NTP una escala de tiempo que se actualiza cada 2,32 segundos (136 años) y una resolución teórica de 2 −32 segundos (233 picosegundos). NTP utiliza una época del 1 de enero de 1900. La primera renovación se produce en 2036, antes del problema del año 2038 de UNIX. [48] [49]
La implementación original del sistema operativo Unix almacenaba la hora del sistema como un entero de 32 bits con signo que representa el número de segundos después de la época Unix : medianoche UTC 00:00:00 del jueves 1 de enero de 1970. Este valor se renovará después de las 03:00: 14:07 UTC del martes 19 de enero de 2038. Este problema se ha solucionado en la mayoría de los sistemas operativos Unix y similares modernos almacenando la hora del sistema como un entero de 64 bits con signo, aunque se deben cambiar las aplicaciones, los protocolos y los formatos de archivo individuales. también.
Al igual que el problema de la transferencia de tiempo de Unix, la versión de 32 bits de gmtime en las bibliotecas de tiempo de ejecución de C en Windows tiene un problema similar. [50]
Este problema ya se manifestó en Access Manager versión 10.1.4.3 de Oracle para Windows. El componente Identity Console establece una cookie que contiene preferencias de UI con una caducidad de 500.000.000 segundos en el futuro (aproximadamente 16 años). Esto es posterior al 19 de enero de 2038, por lo que genera una excepción para ciertas actividades de búsqueda después de las 02:20:48 UTC del 17 de marzo de 2022 porque la llamada gmtime_r() no puede convertir el número proporcionado en una fecha para escribir en la cookie. [51] A pesar de la antigüedad del software (18 de junio de 2009), Oracle emitió un parche número 33983548 el 6 de abril de 2022.
La tercera transferencia de números de semana GPS se producirá el 20 de noviembre de 2038, a las 23:59:37 UTC.
Las primeras computadoras Apple Macintosh almacenan la hora en sus relojes en tiempo real (RTC) y sistemas de archivos HFS como una cantidad de segundos sin firmar de 32 bits desde las 00:00:00 del 1 de enero de 1904. Después de las 06:28:15 del 6 de febrero de 2040, ( es decir, 2 32 −1 segundos desde la época), esto se extenderá hasta 1904: [52] además de esto, HFS+ , el formato predeterminado para todas las computadoras Macintosh recientes de Apple, también se ve afectado. El reemplazo del sistema de archivos de Apple resuelve este problema.
ProDOS para computadoras Apple II solo admite números de año de dos dígitos. Para evitar problemas con el año 2000, Apple emitió una nota técnica indicando que el número del año debía representar 1940-2039. [53] El software para la plataforma puede mostrar incorrectamente fechas que comienzan en 2040, aunque se está llevando a cabo un esfuerzo de terceros para actualizar ProDOS y el software de la aplicación para admitir años hasta 4095. [54]
El 18 de septiembre de 2042, el reloj de hora del día (TODC) en el mainframe IBM S/370 y sus sucesores, incluido el actual zSeries, se renovará. [55]
Los TODC más antiguos se implementaron como un recuento de 64 bits de unidades de 2 −12 microsegundos (0,244 ns), y la base estándar era el 1 de enero de 1900, UT . En julio de 1999 se anunció el reloj TODC extendido, que extendía el reloj hacia la derecha (es decir, los bits extendidos son menos significativos que los bits originales). La resolución real depende del modelo, pero el formato es consistente y, por lo tanto, cambiará después de 2,52 microsegundos . [55]
El valor TODC es accesible para los programas en modo usuario y a menudo se usa para cronometrar y generar ID únicos para eventos.
Si bien IBM ha definido e implementado un formato de hardware más largo (128 bits) en máquinas recientes, que extiende el temporizador en ambos extremos en al menos 8 bits adicionales, muchos programas continúan confiando en el formato de 64 bits, que sigue siendo un subconjunto accesible. del temporizador más largo.
La lógica de planificación de capacidad en el sistema ERP SAP S/4HANA solo admite fechas de finalización hasta el 19 de enero de 2048 (24.855 días a partir del 1 de enero de 1980). Esto se refiere, por ejemplo, a la planificación de la producción, el mantenimiento y la inspección. [56]
Según la especificación única de UNIX para analizar años de dos dígitos utilizando strptime(), "los valores en el rango [69,99] se referirán a los años 1969 a 1999 inclusive y los valores en el rango [00,68] se referirán a los años 2000 a 2068 inclusive ", [57] lo que significa que, cuando lo analiza strptime(), el año de dos dígitos "69" se interpretaría como 1969 en lugar de 2069.
Los programas que almacenan fechas como el número de días desde una fecha arbitraria (o época ) son vulnerables a efectos de rollover o envoltura si los valores no son lo suficientemente amplios como para permitir que los valores de fecha abarquen un rango de tiempo lo suficientemente grande esperado para el solicitud. Los valores binarios de 16 bits con signo se reinvierten después de 32 768 (2 15 ) días a partir de la fecha de época, lo que produce valores negativos. Algunos sistemas mainframe experimentaron fallas de software porque habían codificado fechas como el número de días desde el 1 de enero de 1900, lo que produjo números de días negativos inesperados en la fecha de renovación del 18 de septiembre de 1989. De manera similar, los recuentos de días binarios de 16 bits sin firmar se desbordan después de 65.536 (2 16 ) días, que se truncan a valores cero. Para el software que utiliza una época del 1 de enero de 1900, esto ocurrirá el 6 de junio de 2079. [58]
Algunos (si no todos) los teléfonos Nokia que ejecutan la Serie 40 (como el Nokia X2-00 ) solo admiten fechas hasta el 31 de diciembre de 2079 y, por lo tanto, no podrán mostrar fechas posteriores. Una solución alternativa es utilizar el año 1996, 2024 o 2052 en lugar de 2080 (como años bisiestos compatibles) para mostrar el día de la semana, la fecha y el mes correctos en la pantalla principal. [ cita necesaria ]
Los sistemas que almacenan el año como un valor de dos dígitos 00..99 solo internamente, como muchos RTC, pueden pasar del 31 de diciembre de 2079 a la época IBM PC y DOS de 1980-01-01 .
La API de fecha de archivos de DOS y Windows y las funciones de conversión (como INT 21h /AH=2Ah) admiten oficialmente fechas hasta el 31 de diciembre de 2099, únicamente (aunque el sistema de archivos FAT subyacente teóricamente admitiría fechas hasta 2107). Por lo tanto, los sistemas operativos basados en DOS, así como las aplicaciones que convierten otros formatos al formato FAT/DOS, pueden mostrar un comportamiento inesperado a partir del 1 de enero de 2100.
Otro problema surgirá a finales del 28 de febrero de 2100, ya que 2100 no es un año bisiesto . Como muchas implementaciones comunes del algoritmo de año bisiesto están incompletas o simplificadas, pueden suponer erróneamente que 2100 es un año bisiesto, lo que hace que la fecha pase del 28 de febrero de 2100 al 29 de febrero de 2100, en lugar del 1 de marzo de 2100.
Nintendo DS y GameCube, así como Sony PlayStation 4, sólo permiten a los usuarios establecer fechas hasta el año 2099. En el caso de Nintendo DS, el sistema no adelantará el tiempo más allá del 31 de diciembre de 2099, mientras que GameCube y PS4 aún se extenderá hasta 2100 y más allá, a pesar de que los usuarios de esas consolas de juegos no pueden ingresar manualmente la fecha y la hora hasta esa fecha.
Muchos formatos de archivos, protocolos de comunicaciones e interfaces de aplicaciones existentes emplean una variante del formato de fecha Unix time_t , almacenando el número de segundos desde la época Unix (medianoche UTC, 1 de enero de 1970) como un entero binario de 32 bits sin signo . Este valor se renovará el 7 de febrero de 2106 a las 06:28:15. Es decir, en este momento el número de segundos desde el 1 de enero de 1970 es FFFF FFFF en hexadecimal.
Este problema de representación de almacenamiento es independiente de los programas que almacenan internamente y operan en los tiempos del sistema como valores enteros con signo de 64 bits.
Las marcas de tiempo almacenadas en los sistemas de archivos FAT , introducidas originalmente con 86-DOS 0.42 el 25 de febrero de 1981 y trasladadas a MS-DOS , PC DOS , DR-DOS , etc., se desbordarán a finales del 31 de diciembre de 2107. La fecha de la última modificación El sello (y con DELWATCH 2.0+ también el sello de fecha de eliminación del archivo , y desde DOS 7.0 + opcionalmente también el sello de fecha de último acceso y el sello de fecha de creación ), se almacenan en la entrada del directorio con el año representado como un número de siete bits sin signo (0 –127), en relación con 1980, y por lo tanto no puede indicar ninguna fecha en el año 2108 y años posteriores. Las funciones API definidas para recuperar estas fechas oficialmente solo admiten fechas hasta el 31 de diciembre de 2099.
Esto también afectará el formato del archivo ZIP , ya que utiliza marcas de tiempo de modificación de archivos FAT internamente.
Las fechas GPS se expresan como un número de semana y un número de día de la semana; el número de semana utiliza inicialmente un valor de diez bits y los mensajes de navegación GPS modernizados utilizan un campo de 13 bits. Los sistemas de diez bits se renovarían cada 1024 semanas (aproximadamente 19,6 años) después del domingo 6 de enero de 1980 (la época del GPS ), y los sistemas de 13 bits se renovarían cada 8192 semanas. Los sistemas de trece bits pasarán a cero en 2137. [7] [8]
RISC OS almacena las fechas en centisegundos desde el inicio del lunes 1 de enero de 1900 en cinco bytes (40 bits). Estas marcas de tiempo se utilizan internamente y se exponen en los metadatos del archivo (direcciones de carga y ejecución). Esta época finaliza el 3 de junio de 2248 a las 06:57:57.75 UTC. [59]
Algunos sistemas de cronometraje cuentan nanosegundos desde 1970 utilizando un entero con signo de 64 bits, que se desbordará el 11 de abril de 2262, 23:47:16. La API del lenguaje de programación Go UnixNano es un ejemplo. [60] Otros ejemplos incluyen el objeto Timestamp en Python pandas , [61] C++ crono::nanosegundos, [62] y los temporizadores QEMU . [63]
Los sistemas que utilizan una cadena de 10 caracteres de longitud para registrar la hora Unix pueden tener problemas para informar tiempos superiores a los diez mil millones de segundo después del 20 de noviembre de 2286, a las 17:46:40.
En ext4 , el sistema de archivos predeterminado para muchas distribuciones de Linux, los dos bits inferiores {a,c,m}time_extrase utilizan para ampliar los {a,c,m}timecampos, aplazando el problema del año 2038 al año 2446. [64]
Dentro de este campo "extra" de 32 bits, los dos inferiores los bits se utilizan para ampliar el campo de segundos de 32 bits para que tenga 34 bits de ancho; los 30 bits superiores se utilizan para proporcionar una precisión de marca de tiempo de nanosegundos. Por lo tanto, las marcas de tiempo no deberían desbordarse hasta mayo de 2446. [65]
En escalas de tiempo de miles de años, el calendario gregoriano va por detrás de las estaciones astronómicas. Esto se debe a que la velocidad de rotación de la Tierra se está desacelerando gradualmente , lo que hace que cada día sea ligeramente más largo con el tiempo (ver aceleración de marea y segundo intercalar ) mientras que el año mantiene una duración más uniforme.
En el siglo XIX, Sir John Herschel propuso una modificación del calendario gregoriano con 969 días bisiestos cada 4.000 años, en lugar de los 970 días bisiestos que el calendario gregoriano insertaría durante el mismo período. [66] Esto reduciría el año promedio a 365,24225 días. La propuesta de Herschel haría que el año 4000, y sus múltiplos, fuera común en lugar de bisiesto. Si bien esta modificación se ha propuesto con frecuencia desde entonces, nunca ha sido adoptada oficialmente. [67]
Si bien la mayoría del software (incluidos Excel , JavaScript y R ) reconoce actualmente 4000 y 8000 como años bisiestos (ya que son divisibles por 400), SAS ha adoptado la "regla de los 4000 años". Por lo tanto, con el software actual, las conversiones de fechas entre SAS y otro software dejarán de sincronizarse después del 28 de febrero de 4000. [68] [69]
Microsoft Outlook utiliza la fecha 1 de enero de 4501 como marcador de posición para "ninguno" o "vacío". [70] [71]
El año 10.000 será el primer año gregoriano con cinco dígitos. Todos los años futuros que son potencias de 10, así como las fechas anteriores al décimo milenio antes de Cristo , enfrentan problemas de codificación similares.
Este problema se puede ver en el programa de hoja de cálculo Microsoft Excel a partir de 2023, que almacena fechas como el número de días desde el 31 de diciembre de 1899 (el día 1 es el 1 de enero de 1900) con un día bisiesto ficticio en 1900 si se utiliza el sistema de fechas predeterminado de 1900. Alternativamente, si se utiliza el sistema de fechas de 1904, la fecha se almacena como el número de días desde el 1 de enero de 1904 (el día 1 es el 2 de enero de 1904) y no hay problema de año bisiesto. La fecha máxima admitida para el cálculo es el 31 de diciembre de 9999. [72] [73]
A partir del 14 de septiembre del 30.828, Windows no aceptará fechas posteriores a este día y, al iniciarse, mostrará un error relacionado con la "hora del sistema no válida" en NTFS. Esto se debe a que el valor FILETIME en Windows, que es un valor de 64 bits correspondiente al número de intervalos de 100 nanosegundos desde el 1 de enero de 1601, 00:00:00.0000000 UTC, desbordará su valor máximo posible ese día a las 02:48 :05.4775808UTC. [74]
Los programas que procesan años como valores de 16 bits pueden encontrar problemas al tratar con el año 32.768 o 65.536, dependiendo de si el valor se trata como un entero con o sin signo.
Para el problema del año 32.768 , los años posteriores a 32.767 pueden interpretarse como números negativos, comenzando con −32.768. [75] Es más probable que el problema del año 65.536 se manifieste representando el año 65.536 como el año 0. [76]
El año 100.000 será el primer año gregoriano con seis dígitos.
La API Date de JavaScript almacena fechas como el número de milisegundos desde el 1 de enero de 1970. Las fechas tienen un rango de ±100.000.000 de días desde la época, lo que significa que los programas escritos en JavaScript que utilizan la API Date no pueden almacenar fechas posteriores al 13 de septiembre del año 275.760 d.C. [77]
Ciertos años problemáticos ocurren en un futuro tan lejano (mucho más allá de la probable vida útil de la Tierra , el Sol , la humanidad e incluso más allá de algunas predicciones de la vida del universo ) que se hace referencia a ellos principalmente como cuestiones de interés teórico, bromas o indicaciones de que un problema relacionado no está realmente resuelto para cualquier definición razonable de "resuelto".
El problema del año 292.277.026.596 (aproximadamente2,9 × 10 11 años en el futuro) ocurrirá cuando el tiempo Unix de 64 bits se desborde después de las 15:30:08 UTC del domingo 4 de diciembre del año 292.277.026.596 d.C. [78] [79]
En Microsoft Windows 7, Windows Server 2003, Windows Server 2008 y Windows Vista, la información de inicio de la conexión TCP se almacenaba en centésimas de segundo, utilizando un entero sin signo de 32 bits, lo que provocaba un desbordamiento y fallas en las conexiones TCP después de 497 días. [80]
Microsoft Windows 95 y Windows 98 tuvieron un problema con la sustitución de 2^32 milisegundos en un controlador de dispositivo virtual (VTDAPI.VXD), lo que provocó que los sistemas se bloquearan después de 49,7 días. [81]
.NET hasta la versión 6.0 tenía un error que provocaba que la escalada de subprocesos fallara periódicamente después de 49,7 días debido a un desbordamiento al manejar los milisegundos desde el inicio. [82]
El avión Boeing 787 ha tenido al menos dos problemas de software relacionados con el almacenamiento del tiempo. En 2015, se informó de un error en el que el tiempo se almacenaba en centésimas de segundo, utilizando un entero de 32 bits con signo, y los sistemas fallaban después de 248 días. [83]
En 2020, la FAA emitió una directiva de aeronavegabilidad para un problema en el que, si la aeronave no se apaga por completo antes de alcanzar los 51 días de funcionamiento, los sistemas comenzarán a mostrar datos engañosos. [84]
La plataforma Arduino proporciona un tiempo relativo mediante la función millis(). Esta función devuelve un valor de 32 bits sin firmar para "milisegundos desde el inicio", que está diseñado para renovarse cada 49,71 días. De forma predeterminada, esta es la única fuente de sincronización disponible en la plataforma y los programas deben tener especial cuidado al manejar las reinversiones. [85] Internamente, millis() se basa en contar las interrupciones del temporizador. Ciertos modos de ahorro de energía desactivan las interrupciones y, por lo tanto, impiden que el contador avance durante el modo de suspensión. [86]
También para años históricos puede haber problemas al manejar eventos históricos, por ejemplo:
OS/8 sólo puede almacenar fechas para un período de 8 años...
COS-310, el sistema operativo comercial de DEC para el PDP-8... el sistema de archivos es casi el mismo que OS/8, pero las fechas se registran de manera diferente