En informática , las limitaciones de los tipos de datos y los errores de software pueden provocar errores en el cálculo o la 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 o momentos importantes que han causado o causarán problemas según 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 relacionados 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ó solo tres bits para el año, que representan 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 el sistema operativo Mac clásico comenzaron a congelarse cuando se ejecutaban el 18 de septiembre de 1993. Un problema en la versión para Mac del intérprete creativo de Sierra (Mac SCI) causaba que el juego se "bloqueara" al intentar manejar un retraso debido a un problema que involucraba un desbordamiento. Mac SCI intentaba usar la fecha para determinar cuánto debería durar un retraso obteniendo el tiempo actual en segundos desde el 1 de enero de 1904, la época de Macintosh, y dividiéndolo por 12 horas. La división era procesada por el Motorola 68000 y no se producía si se detectaba un desbordamiento debido a la división, pero Mac SCI continuaba independientemente como si la división hubiera ocurrido, lo que eventualmente resultó en que un retraso de un segundo se tratara como un retraso de 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/OS , que se basa en la cantidad de unidades de 4 microsegundos que han ocurrido 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 la fecha que recibieron menos publicidad que el entonces inminente problema del Y2K.
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 1024 semanas (aproximadamente 19,6 años) después del domingo 6 de enero de 1980 (la época GPS ), la fecha se restablece 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 esta preocupación, los mensajes de navegación GPS modernizados utilizan un campo de 13 bits, que solo se repite cada 8192 semanas (157 años) y no volverá a cero hasta el año 2137 [9].
Muchos programas o conjuntos de datos antiguos utilizaban "9/9/99" como valor no válido para indicar una fecha no resuelta o como un finalizador para indicar que no había más datos en el conjunto. Esto provocó que muchos sistemas se bloquearan al llegar la fecha real que esto representa, el 9 de septiembre de 1999. [7]
En varios puntos del siglo XXI surgirán problemas derivados de ciertas soluciones temporales al problema del Y2K. Algunos programas se adaptaron al Y2K al seguir utilizando años de dos dígitos, pero eligiendo un año arbitrario antes del cual esos años se interpretarían como 20 xx y después como 19 xx . [10]
Por ejemplo, es posible que se haya modificado un programa para que trate los valores de año de dos dígitos 00-68 como referencias del período 2000 a 2068, y los valores 69-99 como referencias del período 1969 a 1999. [11] Un programa de este tipo no podrá tratar correctamente años posteriores a 2068.
Para las aplicaciones que requieren calcular el año de nacimiento (u otro año anterior), este algoritmo se ha utilizado durante mucho tiempo para superar el problema del año 1900 , pero no ha logrado reconocer a personas mayores de 100 años .
Los sistemas que utilizaban una cadena de nueve dígitos para registrar el tiempo en segundos desde la época Unix tuvieron problemas para informar tiempos más allá del milmillonésimo segundo después de la época del 9 de septiembre de 2001 a las 01:46:40 (el "billenium"). Los problemas no fueron generalizados. [12]
Los juegos de Sierra Entertainment para el sistema operativo Mac OS clásico que se habían parcheado con el programa MCDATE o que se habían publicado posteriormente con el parche incorporado comenzaban a congelarse el 28 de mayo de 2007. Al igual que con el problema del año 1993, esto se debía a un problema en el SCI de Mac al intentar usar la fecha para determinar cuánto tiempo debería durar un retraso. Los programas con el parche MCDATE se congelan porque el SCI de Mac toma el número actual de segundos desde la época de Macintosh del 1 de enero de 1904, le resta 432.000.000 de segundos y luego lo divide por 12 horas a través del Motorola 68000, para luego determinar cuánto tiempo deberían durar los retrasos. El 28 de mayo de 2007, el Motorola 68000 nuevamente no divide debido a la protección contra desbordamiento, que el SCI de Mac ignora. [4]
Algunos sistemas tuvieron problemas una vez que llegó el año 2010. Algunos medios de comunicación lo denominaron 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 la codificación de números BCD . Los números del 0 al 9 se codifican tanto en hexadecimal como en BCD como 00 16 a 09 16 . Pero el número decimal 10 se codifica en hexadecimal como 0A 16 y en BCD como 10 16 . Por lo tanto, un BCD 10 16 interpretado como una 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 programas de telefonía móvil informaban incorrectamente las fechas de los mensajes como 2016 en lugar de 2010. Windows Mobile fue el primer programa afectado por este problema técnico; 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, lo que provocó un error de programa . [18]
El fallo más importante de este tipo se produjo en Alemania, donde más de 20 millones de tarjetas bancarias se volvieron 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. Por lo tanto, 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ó la 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 que contaba el número de décimas de segundo desde el 1 de enero de 2000. [21]
En 2019, se produjo el segundo cambio de 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 los años en Japón se denominan tradicionalmente por nombres de era que corresponden al reinado de cada emperador, esto resultó en un nuevo nombre de era, Reiwa (令和) , después de la ascensión al trono de Naruhito 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 computadoras, la mayoría del software no había sido probado para garantizar un comportamiento correcto en un cambio de era, mientras que las pruebas se complicaron aún más por el hecho de que el nuevo nombre de era no fue revelado hasta el 1 de abril de 2019. Por lo tanto, se esperaban errores de software que no anticiparan una nueva era.
Los videojuegos WWE 2K20 y Star Wars Jedi: Fallen Order dejaron de funcionar el 1 de enero de 2020, cuando el año cambió de fecha. Los fallos solo se pudieron evitar reiniciando el año a 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 pudieron aceptar tarjetas de crédito como forma de pago a partir de 2020. Se implementó una solución alternativa, pero requirió que cada parquímetro se actualizara individualmente. En Nueva York, no se esperaba que los parquímetros se arreglaran hasta el 9 de enero. [25] [26]
En Polonia, 5.000 cajas registradoras dejaron de imprimir la fecha correctamente. [27]
Los relojes inteligentes deportivos Suunto mostraban un error al calcular los días de la semana que se presentaban con un paso de +2 (por ejemplo, VIERNES en lugar de MIÉRCOLES, SÁBADOS en lugar de JUEVES). En el caso de los relojes Suunto Spartan, el error se solucionó con la versión de firmware 2.8.32. [28]
El panel de control de las versiones 6, 7 y 8 del sistema operativo Mac OS Classic solo permite establecer la fecha hasta el 31 de diciembre de 2019, aunque el sistema puede seguir 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 trabajar con años mayores a 2020 o más, debido al hecho de que el programa fue diseñado para operar dentro de una ventana de tiempo de 100 años que va desde 1920 a 2019. Como resultado, la fecha solo se puede establecer 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 las estadísticas de batería y carga a partir de 2021. Los dispositivos afectados no reportarían estadísticas de uso, por lo que dejarían esas secciones 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. Los números de actualización del componente de escaneo de malware de Microsoft Exchange se vieron especialmente afectados , ya que parecen utilizarse para una comprobació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 de la época del GPS. [36] [37] El problema se resolvió el 17 de agosto de 2022. [38]
Los lectores de tarjetas de pago en las gasolineras de Nueva Zelanda no pudieron soportar 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, ya que el primero se bloqueaba al intentar cargar el juego y el segundo afirmaba que los datos guardados estaban dañados. Ambos juegos tuvieron que configurarse para el día siguiente, el 1 de marzo de 2024, para que funcionaran correctamente. [40] [41] [42]
En Japón, algunos sistemas informáticos antiguos que utilizan el calendario japonés y que no han sido actualizados aún cuentan los años según la era Shōwa . El año 2025 corresponde en esos sistemas a Shōwa 100, lo que puede causar problemas si el software supone dos dígitos para el año. [43]
Algunos sistemas almacenan el año como un byte único a partir de 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 signo : algunos han sido codificados por error con un byte con signo que solo 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 causar un comportamiento impredecible. Varios programas de discos ópticos que funcionan con el formato ISO 9660 se ven afectados por esto. [44]
A finales de los años 1970, en los sistemas Data General Nova y Eclipse, la World Computer Corporation (que realizaba 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; tenga en cuenta que 1900+128=2028), 12 meses (4 bits) y 31 días (5 bits). Esto permitió que las fechas se pudieran comparar directamente utilizando funciones sin signo. Algunos sistemas, incluido el HP 3000 , todavía utilizan este formato, aunque consultores externos han desarrollado un parche. [45]
Palm OS utiliza tanto números enteros con signo con la época de 1970 como números enteros sin signo con la época de 1904 para diferentes funciones del sistema [46], como por ejemplo para 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 de 2038, Palm OS también utiliza un campo de 7 bits para almacenar el valor del año, con una época diferente que cuenta 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 consisten en 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 renueva 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 ocurre 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 con signo de 32 bits que representaba la cantidad de segundos transcurridos desde la época Unix (1 de enero de 1970, 00:00:00 UTC). Este valor se actualizará después del 19 de enero de 2038, 03:14:07 UTC. 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 con signo de 64 bits, aunque también se deben cambiar las aplicaciones, los protocolos y los formatos de archivo individuales.
Al igual que el problema de renovación 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 ha manifestado en la versión 10.1.4.3 de Oracle Access Manager para Windows. El componente Identity Console establece una cookie que contiene preferencias de la interfaz de usuario con una caducidad de 500.000.000 segundos en el futuro (unos 16 años). Esto es posterior al 19 de enero de 2038 y, por lo tanto, genera una excepción para determinadas actividades de búsqueda posteriores a 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.
El tercer cambio de número de semana del GPS ocurrirá el 20 de noviembre de 2038, a las 23:59:37 UTC.
Los primeros ordenadores Apple Macintosh almacenaban la hora en sus relojes de tiempo real (RTC) y en los sistemas de archivos HFS como un número de segundos de 32 bits sin signo 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 volverá a 1904: [52] Además de esto, HFS+ , el formato predeterminado para todos los ordenadores Macintosh recientes de Apple, también se ve afectado. El sistema de archivos de Apple que lo reemplazó resuelve este problema.
ProDOS para las computadoras Apple II solo admite números de año de dos dígitos. Para evitar problemas con el Y2K, Apple emitió una nota técnica que indicaba que el número de año debía representar el período 1940-2039. [53] El software para la plataforma puede mostrar incorrectamente las fechas que comienzan en 2040, aunque se está realizando un esfuerzo de terceros para actualizar ProDOS y el software de la aplicación para que admitan años hasta 4095. [54]
El 18 de septiembre de 2042, el reloj de hora del día (TODC) del mainframe IBM S/370 y sus sucesores, incluido el zSeries actual, se renovará. [55]
Los TODC más antiguos se implementaron como un conteo de 64 bits de 2 −12 unidades de 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 extendió 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, se renovará después de 2 52 microsegundos. [55]
El valor TODC es accesible para los programas en modo usuario y se utiliza a menudo para cronometrar y generar identificadores ú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 dependiendo del formato de 64 bits, que sigue siendo un subconjunto accesible del temporizador más largo.
La lógica de planificación de la capacidad en el sistema ERP SAP S/4HANA sólo 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 afecta, 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 se analiza con strptime(), el año de dos dígitos "69" se interpretará 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 acumulación o envoltura si los valores no son lo suficientemente amplios para permitir que los valores de fecha abarquen un rango de tiempo lo suficientemente grande esperado para la aplicación. Los valores binarios de 16 bits con signo se acumulan después de 32.768 (2 15 ) días desde la fecha de la é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 acumulación del 18 de septiembre de 1989. De manera similar, los recuentos de días binarios sin signo de 16 bits 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 teléfonos Nokia (si no todos) que funcionan con 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 requerida ]
Los sistemas que almacenan el año como un valor de dos dígitos 00..99 internamente solamente, como muchos RTC, pueden trasladarse desde el 31 de diciembre de 2079 a la época de IBM PC y DOS del 01-01-1980 .
Las API y funciones de conversión de fechas de archivos de DOS y Windows (como INT 21h /AH=2Ah) admiten oficialmente fechas hasta el 31 de diciembre de 2099 únicamente (aunque el sistema de archivos FAT subyacente admitiría teóricamente fechas hasta el año 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.
De la misma manera, la Nintendo DS y la GameCube, así como la Sony PlayStation 4, sólo permiten a los usuarios fijar fechas hasta el año 2099. En el caso de la Nintendo DS, el sistema no hará avanzar el tiempo más allá del 31 de diciembre de 2099, mientras que la GameCube y la PS4 sí lo harán hasta el año 2100 y más allá, a pesar de que los usuarios de esas consolas de juego no pueden introducir manualmente la fecha y la hora con esa antelación.
Otro problema surgirá al final del 28 de febrero de 2100, ya que 2100 no es un año bisiesto . Como muchas implementaciones comunes del algoritmo del año bisiesto son incompletas o están simplificadas, pueden asumir 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.
Muchos formatos de archivos, protocolos de comunicación e interfaces de aplicaciones existentes emplean una variante del formato de fecha Unix time_t , que almacena el número de segundos transcurridos desde la época Unix (medianoche UTC, 1 de enero de 1970) como un entero binario de 32 bits sin signo . Este valor se actualizará el 7 de febrero de 2106 a las 06:28:15 UTC. Es decir, en este momento el número de segundos transcurridos 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 y operan internamente en tiempos del sistema como valores enteros con signo de 64 bits.
Las marcas de fecha y hora almacenadas en los sistemas de archivos FAT , introducidas originalmente con 86-DOS 0.42 en 1981 y trasladadas a MS-DOS , PC DOS , DR-DOS , etc., se desbordarán al final del 31 de diciembre de 2107. La marca de fecha de la última modificación (y con DELWATCH 2.0+ también la marca de fecha de eliminación de archivo , y desde DOS 7.0+ opcionalmente también la marca de fecha del último acceso y la marca 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), relativo a 1980, y por lo tanto no pueden indicar ninguna fecha en el año 2108 y posteriores. Las funciones API definidas para recuperar estas fechas oficialmente solo admiten fechas hasta el 31 de diciembre de 2099.
Esto también afectará al formato de archivo ZIP , ya que utiliza internamente marcas de tiempo de modificación de archivos FAT.
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 inicialmente utilizaba un valor de diez bits y los mensajes de navegación GPS modernizados utilizaban 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 GPS ), y los sistemas de 13 bits se renovarían cada 8192 semanas. Los sistemas de trece bits se renovarán hasta cero en 2137. [7] [8]
RISC OS almacena las fechas en centisegundos desde el 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 pandas de Python , [61] chrono::nanoseconds de C++ , [62] y los temporizadores QEMU . [63]
Los sistemas que utilizan una cadena de 10 caracteres para registrar la hora Unix pueden tener problemas para informar horas posteriores al 20 de noviembre de 2286, a las 17:46:39, diez mil millones de segundos después de la época Unix.
En ext4 , el sistema de archivos predeterminado para muchas distribuciones de Linux, los dos bits inferiores de {a,c,m}time_extrase utilizan para ampliar los {a,c,m}timecampos, lo que posterga el problema del año 2038 hasta el año 2446. [64]
Dentro de este campo "extra" de 32 bits, los dos bits inferiores se utilizan para ampliar el campo de segundos de 32 bits para que tenga un ancho de 34 bits; 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 va reduciendo gradualmente , lo que hace que cada día sea ligeramente más largo con el tiempo (véase aceleración de las mareas 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 4000 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, fueran comunes en lugar de bisiestos. Si bien esta modificación se ha propuesto a menudo desde entonces, nunca se ha adoptado oficialmente. [67]
Aunque la mayoría de los programas informáticos (incluidos Excel , JavaScript y R ) reconocen actualmente los años 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 otros programas dejarán de estar sincronizadas 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 sean potencias de 10, así como las fechas anteriores al décimo milenio a. C. , se enfrentan a 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 las 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 fecha predeterminado de 1900. Alternativamente, si se utiliza el sistema de fecha 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]
En Windows, la FILETIMEestructura almacena el número de intervalos de 100 nanosegundos desde las 00:00:00.0000000 UTC del 1 de enero de 1601 como un entero de 64 bits con signo. Este valor superará su valor máximo posible a las 02:48:05.4775808 UTC del 14 de septiembre de 30828, fecha a partir de la cual Windows no aceptará fechas posteriores a ese día y mostrará errores de "hora del sistema no válida" en NTFS. [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 signo 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 al representar el año 65.536 como el año 0. [76]
Los archivos de biblioteca estática creados por el comando ar de Unix almacenan las marcas de tiempo como una cadena ASCII que contiene un número decimal de segundos después de la época de Unix (1 de enero de 1970, 00:00:00 UTC), con un límite de 12 caracteres ASCII. Este valor se actualizará después de la 1:46:39 del 27 de septiembre de 33658.
El año 100.000 será el primer año gregoriano con seis dígitos.
El problema del año 292.277.026.596 (aproximadamente2,92 × 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] Este año está tan lejos en el futuro (mucho más allá de la probable vida útil de la Tierra , el Sol , la humanidad e incluso más allá de algunas predicciones sobre la vida útil del universo ) que se hace referencia a él principalmente como una cuestión de interés teórico, una broma o una indicación de que versiones anteriores como el problema del año 2038 no se pueden "resolver" verdaderamente para siempre.
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 causaba un desbordamiento y que las conexiones TCP fallaran después de 497 días. [80]
Microsoft Windows 95 y Windows 98 tenían un problema con un retraso de 2 milisegundos en un controlador de dispositivo virtual (VTDAPI.VXD), que causaba 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 causaba que el ascenso de nivel del grupo 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 de 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 se bloqueaban 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 a través de la función millis(). Esta función devuelve un valor de 32 bits sin signo 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 tiempo disponible en la plataforma y los programas deben tener especial cuidado para manejar las renovaciones. [85] Internamente, millis() se basa en el conteo de interrupciones del temporizador. Ciertos modos de ahorro de energía deshabilitan las interrupciones y, por lo tanto, impiden que el contador avance durante el modo de suspensión. [86]
También en el caso de los años históricos pueden surgir problemas a la hora de gestionar eventos históricos, por ejemplo:
OS/8 sólo puede almacenar fechas correspondientes a 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 forma diferente