Errores de formato y almacenamiento de hora

En informática , las limitaciones de los tipos de datos y los errores de software pueden provocar fallos en el cálculo o la visualización de fechas y horas . Estos fallos suelen ser consecuencia de un desbordamiento aritmético , pero también pueden deberse a otros problemas. El ejemplo más conocido de este tipo es el problema del año 2000 , pero existen muchas otras fechas o horas clave que han causado o causarán problemas dependiendo de diversas deficiencias de programación.

El 5  de enero de 1975, el campo de 12 bits utilizado para las fechas en el sistema operativo TOPS-10 para las computadoras DEC PDP-10 sufrió un desbordamiento, en un error conocido como "DATE75". El valor del campo se calculaba multiplicando el número de años transcurridos desde el 1 de enero de 1964 por 12, sumando el número de meses transcurridos desde enero, multiplicando el resultado por 31 y sumando el número de días transcurridos desde el inicio del mes. El valor máximo que se puede representar con un entero sin signo ^de  12 bits es 2¹² − 1 = 4095 , y el valor de 4095 representa el 4  de enero de 1975.${\displaystyle (((11{\text{ years since 1964}})\times 12)+0{\text{ months since January}})\times 31)+3{\text{ days since start of the month}}=4095}$

Por lo tanto, el 4 de  enero de 1975 es la última fecha codificable. El parche "DATE-75" extendió la última fecha codificable al 1 de  febrero de 2052, haciendo que la fecha de desbordamiento fuera el 2  de febrero de 2052, al usar 3 bits de reserva de otros campos en los metadatos del sistema de archivos , pero esto a veces causó problemas con el software que usaba esos bits para sus propios fines. Algunos programas podrían haber admitido el uso de un bit adicional para la fecha, pero tenían problemas con bits adicionales, lo que podría haber resultado en algunos errores el 9 de enero de 1986. ^{[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]} 

El sistema operativo OS/8 de Digital Equipment Corporation para la computadora PDP-8 utilizaba un nibble de cuatro bits con signo para almacenar el número de años transcurridos desde 1970, y esto solo podía representar los años de 1970 a 1977. ^{[ 5 ] [ 6 ]}

Esto se reconoció cuando se desarrolló el sistema operativo COS-310 y las fechas se registraron de manera diferente. ^{[ 7 ]}

Varios juegos de Sierra Entertainment lanzados para el Mac OS clásico comenzaron a congelarse al ejecutarse el 18  de septiembre de 1993. Un problema en la versión para Mac del Creative Interpreter de Sierra (Mac SCI) provocaba que el juego se "bloqueara" al intentar gestionar un retraso debido a un problema de desbordamiento. Mac SCI intentaba usar la fecha para determinar la duración del retraso obteniendo la hora actual en segundos desde el 1 de  enero de 1904, la época de Macintosh, y dividiéndola entre 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 como si la división se hubiera producido, lo que finalmente resultaba 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 . ^{[ 8 ] [ 9 ]}

En el sistema operativo Domain/OS de Apollo Computer , el tiempo absoluto se almacenaba como un entero con signo de 48 bits que representaba el número de unidades de 4 microsegundos desde el 1 de enero de 1980. Este valor se desbordó el 2 de noviembre de 1997, lo que hizo que los sistemas sin parchear quedaran inutilizables. ^{[ 5 ] [ 10 ]}  

En los últimos meses previos al año 2000, se produjeron otros dos hitos relacionados con fechas que recibieron menos publicidad que el entonces inminente problema del efecto 2000.

Los sistemas que utilizaban una cadena de nueve dígitos para registrar el tiempo en segundos desde la época Unix presentaban problemas al informar tiempos posteriores al segundo milmillonésimo tras la época del 9 de  septiembre de 2001 a las 01:46:40 (el "billón"). Los problemas no fueron generalizados. ^{[ 5 ] [ 14 ]}

Los juegos de Sierra Entertainment para el Mac OS clásico que fueron parcheados con el programa MCDATE o lanzados posteriormente con el parche incorporado comenzaron a bloquearse el 28  de mayo de 2007. Al igual que con el problema del año 1993 , esto se debió a un problema en el Mac SCI al intentar usar la fecha para determinar la duración de un retraso. Los programas con el parche MCDATE se bloquean porque el Mac SCI toma el número actual de segundos desde la época Macintosh del 1 de  enero de 1904, le resta 432.000.000  de segundos y luego divide por 12  horas a través del Motorola 68000 para determinar la duración de los retrasos. El 28  de mayo de 2007, el Motorola 68000 nuevamente no realiza la división debido a la protección contra desbordamiento, que el Mac SCI ignora. ^{[ 8 ]}

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". ^{[ 15 ]}

La principal fuente de problemas radicaba en la confusión entre la codificación hexadecimal y la codificación BCD de los números. Los números del 0 al 9 se codifican tanto en hexadecimal como en BCD como 00 ₁₆ a 09 _16. Sin embargo, el número decimal 10 se codifica en hexadecimal como 0A ₁₆ y en BCD como 10 _16. Por lo tanto, un valor BCD de 10 ₁₆ interpretado como una codificación hexadecimal representa erróneamente el número decimal 16.

Por ejemplo, el protocolo SMS utiliza la codificación BCD para las fechas, por lo que algunos programas de teléfonos móviles informaban incorrectamente las fechas de los mensajes como 2016 en lugar de 2010. Windows Mobile fue el primer software del que se informó que se vio afectado por este fallo; 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. ^{[ 5 ] [ 16 ] [ 17 ]}

El fallo más notable 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 dejaron de funcionar. ^{[ 18 ]}

Otros sistemas afectados incluyen terminales EFTPOS , ^{[ 19 ]} y la PlayStation 3 (excepto el modelo Slim). ^{[ 20 ]}

La PlayStation 3 de Sony trató erróneamente el año 2010 como bisiesto , por lo que el inexistente 29  de febrero de 2010 se mostró el 1  de marzo de 2010, causando un error de programa . ^{[ 5 ] [ 21 ]}

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. ^{[ 5 ] [ 22 ]} Esto hace que el año parezca ser 1911 (Año 0) si se utilizan representaciones de 2 dígitos.

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 sin signo de 32 bits que contaba el número de décimas de segundo desde el 1  de enero de 2000. ^{[ 23 ]}

Los videojuegos WWE 2K20 y Star Wars Jedi: Fallen Order fallaron el 1 de enero de  2020, cuando comenzó el año. Los fallos solo podían solucionarse reiniciando el año a 2019 hasta que se lanzara un parche. ^{[ 24 ] [ 25 ]} Además, Crystal Reports 8.5 no generaba informes específicos a partir de 2020. ^{[ 26 ]}

Los parquímetros Parkeon en la ciudad de Nueva York y otras localidades dejaron de aceptar tarjetas de crédito como forma de pago a partir de 2020. Se implementó una solución alternativa, pero requirió la actualización individual de cada parquímetro. En Nueva York, no se esperaba que los parquímetros estuvieran reparados hasta el 9 de enero. ^{[ 27 ] [ 28 ]}

En Polonia, 5000 cajas registradoras dejaron de imprimir correctamente las fechas. ^{[ 29 ]}

Los relojes inteligentes deportivos Suunto presentaban un error al calcular los días de la semana, mostrando días con dos días de diferencia respecto a sus fechas reales (por ejemplo, VIE en lugar de MIÉ, SÁB en lugar de JUE). En el caso de los relojes Suunto Spartan, el error se corrigió con la versión de firmware 2.8.32. ^{[ 30 ]}

Usuarios de Samsung informaron que los teléfonos con la actualización 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 mostraban las estadísticas de uso, dejando esas secciones en blanco. ^{[ 34 ] [ 35 ]}

Las fechas almacenadas en el formato aammddHHMM convertidas a un entero con signo de 32 bits desbordaron el 1  de enero de 2022, ya que ^2³¹ = 2147483648. Se vieron particularmente afectados los números de actualización del componente de análisis de malware de Microsoft Exchange , que aparentemente se utilizan para una comprobación matemática para determinar la última actualización. ^{[ 36 ] [ 37 ]}

Los automóviles Honda y Acura fabricados entre 2004 y 2012 que contenían sistemas de navegación GPS mostraban incorrectamente el año como 2002. Este problema se debió a un desbordamiento en la época GPS. ^{[ 38 ] [ 39 ]} El problema se resolvió el 17 de agosto de 2022. ^{[ 40 ]}

Los lectores de tarjetas de pago en las gasolineras de Nueva Zelanda no pudieron gestionar el año bisiesto y no pudieron dispensar gasolina correctamente. ^{[ 41 ]}

Dos videojuegos, EA Sports WRC y Theatrhythm Final Bar Line , también sufrieron problemas relacionados con el año bisiesto: el primero se bloqueaba al intentar cargar el juego y el segundo indicaba que los datos de guardado estaban dañados. Ambos juegos tuvieron que configurarse para el día siguiente, el 1 de  marzo de 2024, para que funcionaran correctamente. ^{[ 42 ] [ 43 ] [ 44 ]}

En diciembre de 2024, se descubrió un error de 30 años de antigüedad en todas las versiones de HCL Notes . Al iniciar el servidor a partir del 13  de diciembre de 2024, un desbordamiento impedía que el enrutador de correo cargara su configuración, por lo que no se entregaba ningún correo. Al día siguiente se publicaron parches para todas las versiones compatibles. ^{[ 45 ]}

En Japón, algunos sistemas informáticos antiguos que utilizan el calendario japonés y que no se han actualizado siguen contando los años según la era Shōwa . En esos sistemas, el año 2025 corresponde al año 100 de la era Shōwa, lo que puede causar problemas si el software asume dos dígitos para el año. ^{[ 46 ]}

En España, todos los trenes de la clase Talgo AVRIL dejaron de funcionar el 1  de enero de 2025 debido a un error en el manejo de fechas en el módulo de carga de la batería, lo que provocó retrasos y cancelaciones, ya que los pasajeros fueron reubicados en otros trenes. ^{[ 47 ] [ 48 ]} Se implementó una solución al día siguiente, restableciendo el servicio regular. ^{[ 49 ]}

Un error en el datecomando de uutils, una reescritura en Rust de las utilidades principales de GNU , provocó que las actualizaciones automáticas en Ubuntu 25.10 dejaran de funcionar. ^{[ 50 ] [ 51 ]}

La hora del sistema en la consola Xbox 360 solo se puede adelantar hasta las 23:59 del 31  de diciembre de 2025. El sistema seguirá avanzando hasta 2026 y más allá mediante la conectividad Xbox Live ; ^{[ 52 ]} sin embargo, los usuarios no pueden configurar la fecha del sistema más allá de este punto debido a una limitación de software dentro del panel de control de Microsoft . ^{[ 53 ]}

Algunos sistemas heredados almacenan el año como un desplazamiento de un byte desde 1900, lo que proporciona un rango de 255 (8 bits) y permite representar fechas hasta 2155 de forma segura. Sin embargo, no todos los sistemas utilizan un byte sin signo : algunos se han codificado erróneamente con un byte con signo, lo que solo permite un rango de 127  años. Esto significa que el campo de fecha en el software será incorrecto después de 2027 y puede provocar un comportamiento impredecible. Varios programas de discos ópticos que funcionan con el formato ISO 9660 se ven afectados por esto. ^{[ 54 ]}

A finales de la década de 1970, en los sistemas Data General Nova y Eclipse, World Computer Corporation (que desarrollaba aplicaciones para cooperativas de crédito) creó un formato de fecha con un campo de fecha de 16 bits, que utilizaba siete bits para el año, cuatro para el mes y cinco para el día. Esto permitía comparar directamente las fechas mediante funciones sin signo. Algunos sistemas, como el HP 3000 , todavía utilizan este formato, aunque consultores externos han desarrollado un parche. ^{[ 55 ]}

Palm OS utiliza enteros con signo de la época de 1970, así como enteros sin signo de la época de 1904, para diferentes funciones del sistema, ^{[ 56 ]} como el reloj del sistema y las fechas de los archivos (véase 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 comienza en 1904, lo que resulta en un año máximo de 2031, 127 años después de 1904. ^{[ 57 ]}

El Protocolo de Tiempo de Red (NTP) 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 los segundos y otra de 32 bits para las fracciones de segundo, lo que le da a NTP una escala de tiempo que se reinicia cada 2³² ^segundos (136  años) y una resolución teórica de 2⁻³² ^segundos (233  picosegundos). NTP utiliza una época del 1  de enero de 1900. El primer reinicio ocurre en 2036, antes del problema del año 2038 de UNIX. ^{[ 5 ] [ 58 ] [ 59 ]}

El mismo problema también afecta a algunas implementaciones de LISP. ^{[ 60 ]}

Los ordenadores Apple Mac hasta macOS X Snow Leopard almacenaban la hora en sus relojes en tiempo real (RTC) y sistemas de archivos HFS como un número de segundos sin signo 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 ³² − 1 segundos desde la época), esto volverá a 1904; ^{[ 5 ] [ 63 ]} además de esto, HFS+ , anteriormente el sistema de archivos predeterminado para la mayoría de los ordenadores Apple, también se ve afectado. Apple File System , que reemplaza a HFS y HFS+, resuelve este problema.

ProDOS, que se ejecutaba en ordenadores Apple II , solo admite números de año de dos dígitos. Para evitar problemas con el efecto 2000, Apple emitió una nota técnica indicando que el número de año debía representar el período 1940-2039. ^{[ 64 ]} El software de la plataforma puede mostrar incorrectamente fechas a partir de 2040, aunque se está trabajando con terceros para actualizar ProDOS y el software de aplicación para que admitan años hasta 4095. ^{[ 65 ]}

El 18 de  septiembre de 2042, el Reloj de Hora del Día (TODC) de la línea de mainframes IBM System/370 y sus sucesores, incluida la actual serie IBM Z , se reiniciará. ^{[ 5 ] [ 66 ]}

Los TODC más antiguos se implementaban como un conteo de 64 bits de unidades de 2 ⁻¹² 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, se reiniciará después de 2 ⁵² microsegundos. ^{[ 66 ]}

El valor TODC es accesible para los programas en modo de usuario y se utiliza con frecuencia para la sincronización y para generar identificadores únicos para los eventos.

Si bien IBM ha definido e implementado un formato de hardware más largo (de 128 bits) en las máquinas recientes, que extiende el temporizador en ambos extremos en al menos 8 bits adicionales, muchos programas siguen dependiendo del formato de 64 bits, que permanece como un subconjunto accesible del temporizador más largo.

La programación del plan de mantenimiento en el sistema ERP SAP S/4HANA solo admite fechas de finalización hasta el 19 de  enero de 2048 (24 855  días desde el 1  de enero de 1980, lo que equivale a 2,31 ^segundos redondeados a días completos). Esto afecta a las herramientas de planificación de producción, mantenimiento e inspección. ^{[ 67 ]} Este problema se ha corregido en actualizaciones más recientes, que admiten fechas hasta el año 9999.

Según la Especificación UNIX Única para analizar años de dos dígitos usando 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", ^{[ 5 ] [ 68 ]} lo que significa que, cuando se analiza con strptime(), el año de dos dígitos "69" se interpretaría como 1969 en lugar de 2069.

Algunos (si no todos) los teléfonos Nokia con procesador Series 40 (como el Nokia X2-00 ) solo admiten fechas hasta el 31  de diciembre de 2079, por lo que no podrán mostrar fechas posteriores. Una solución alternativa consiste en usar los años 1996, 2024 o 2052 en lugar de 2080 (ya que son años bisiestos compatibles) para mostrar correctamente el día de la semana, la fecha y el mes en la pantalla principal.

Muchos sistemas IBM PC y DOS almacenan internamente el año como un valor de dos dígitos desde 1980, al igual que muchos RTC, y estos se reiniciarán después del 31  de diciembre de 2079.

Las funciones de conversión y API de fechas de archivos de DOS y Windows (como INT 21h /AH=2Ah) admiten oficialmente fechas hasta el 31 de diciembre de 2099 (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, podrían presentar un comportamiento inesperado a partir del 1 de enero de 2100.  

Asimismo, la Nintendo DS, la GameCube y la Sony PlayStation 4 solo permiten a los usuarios configurar fechas hasta el año 2099. En el caso de la Nintendo DS, el sistema no avanzará el tiempo más allá del 31  de diciembre de 2099, mientras que la GameCube y la PS4 seguirán avanzando hasta el año 2100 y posteriores, aunque los usuarios de esas consolas no puedan introducir manualmente la fecha y la hora con tanta antelación.

Muchos formatos de archivo, protocolos de comunicación e interfaces de aplicaciones existentes emplean una variante del formato de fecha Unixtime_t , almacenando el número de segundos transcurridos desde la época Unix (medianoche UTC, 1  de enero de 1970) como un entero binario sin signo de 32 bits. Este valor se reiniciará el 7  de febrero de 2106 a las 06:28:16  UTC. Es decir, en ese momento el número de segundos transcurridos desde el 1  de enero de 1970 está FFFFFFFFen formato hexadecimal. ^{[ 5 ]}

Este problema de representación de almacenamiento es independiente de los programas que internamente almacenan y operan con la hora del sistema como valores enteros con signo de 64 bits.

Las marcas de tiempo de fecha almacenadas en sistemas de archivos FAT , introducidas originalmente con 86-DOS 0.42 en 1981 y llevadas a MS-DOS , PC DOS , DR-DOS , etc., se desbordarán al final del 31  de diciembre de 2107. ^{[ 5 ]} La marca de fecha de ú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 de ú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 puede indicar ninguna fecha en el año 2108 y posteriores. Las funciones de API definidas para recuperar estas fechas oficialmente solo admiten fechas hasta el 31  de diciembre de 2099.

Esto también afectará a los archivos ZIP , ya que internamente utilizan 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, utilizando inicialmente el número de semana un valor de diez bits y los mensajes de navegación GPS modernizados un campo de 13 bits. Los sistemas de diez bits se reiniciaban 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 reiniciaban cada 8192 semanas. Los sistemas de trece bits se reiniciarán a cero en 2137. ^{[ 5 ] [ 11 ] [ 12 ]} 

RISC OS almacena las fechas como centisegundos (centésimas de segundo) 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 de los archivos (direcciones de carga y ejecución). ^{[ 70 ]} Este valor se desbordará el 3  de junio de 2248 a las 06:57:57.75  UTC. ^{[ 5 ]}

Algunos sistemas de cronometraje de alta resolución cuentan nanosegundos desde el 1 de enero de 1970 usando un entero con signo de 64 bits, que se desbordará el 11 de abril de 2262 a las 23:47:16  UTC. La API del lenguaje de programación GoUnixNano es un ejemplo. ^{[ 71 ]} Otros ejemplos incluyen el objeto Timestamp en pandas de Python , ^{[ 72 ]} la chronoclase en C++ cuando se establece a precisión de nanosegundos, ^{[ 73 ]} y los temporizadores QEMU . ^{[ 74 ]}

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  UTC, diez mil millones de segundos después de la época Unix. ^{[ 5 ]}

En ext4 , el sistema de archivos predeterminado para muchas distribuciones de Linux, los dos bits inferiores {a,c,m}time_extrase utilizan para extender los {a,c,m}timecampos, posponiendo el problema del año 2038 hasta el año 2446. ^{[ 75 ]} Dentro de este campo "extra" de 32 bits, los dos bits inferiores se utilizan para extender el campo de segundos a un entero con signo de 34 bits; los 30 bits superiores se utilizan para proporcionar precisión de marca de tiempo de nanosegundos. Por lo tanto, las marcas de tiempo no se desbordarán hasta mayo de 2446. ^{[ 76 ]}

En escalas de tiempo de miles de años, el calendario gregoriano se desfasa con respecto a las estaciones astronómicas. Esto se debe a que la velocidad de rotación de la Tierra disminuye 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 al 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. ^{[ 77 ]} 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 con frecuencia desde entonces, nunca se ha adoptado oficialmente. ^{[ 78 ]}

Si bien la mayoría del software (incluidos Excel , JavaScript y R ) reconoce actualmente los años 4000 y 8000 como bisiestos (ya que son divisibles por 400), SAS ha adoptado la "  regla del año 4000". Por lo tanto, con el software actual, las conversiones de fechas entre SAS y otros programas se desincronizarán después del 28  de febrero de 4000. ^{[ 79 ] [ 80 ]}

Microsoft Outlook utiliza el 1  de enero de 4501 como marcador de posición para "ninguno" o "vacío". ^{[ 5 ] [ 81 ] [ 82 ]}

El año 10.000 será el primer año gregoriano con cinco dígitos. Los sistemas que solo permiten hasta cuatro dígitos para el año tendrán problemas para manejar todos los años futuros que sean potencias de 10, así como las fechas anteriores al décimo milenio a . C.

La versión 7 de UUID utiliza una marca de tiempo de 48 bits que se desbordará en el año 10889 d. C. ^{[ 86 ]}

En el lenguaje de programación C# , o cualquier lenguaje que utilice .NET , la DateTimeestructura almacena marcas de tiempo absolutas como el número de décimas de microsegundo (10 ⁻⁷  s, conocidas como "ticks" ^{[ 87 ]} ) desde la medianoche (00:00:00.0000000  UTC) del 1  de enero de 1  d. C. en el calendario gregoriano proleptico , ^{[ 88 ]} que desbordará un entero con signo de 64 bits el 14  de septiembre de 29,228 a las 02:48:05.4775808  UTC. ^{[ 5 ] [ 89 ]} Las estructuras de mantenimiento de tiempo en muchas de las aplicaciones y servicios de Microsoft tienen una resolución de 100 nanosegundos, como el tipo de datos de Power AutomateTIME , ^{[ 90 ]} la GETCURRENTTICKSconsulta en Azure Cosmos DB , ^{[ 91 ]} y el TimeSpanparámetro en varios comandos de Windows PowerShell , ^{[ 92 ]} y todos estos enfrentarán problemas similares. Sin embargo, las fechas posteriores al 31  de diciembre de 9999 a las 23:59:59.9999999  UTC se consideran "no compatibles" y las operaciones de tiempo generarán errores intencionalmente cuando los cálculos de otro modo darían como resultado fechas posteriores a 9999. ^{[ 93 ]}

En los sistemas operativos WindowsFILETIME , la estructura almacena el número de décimas de microsegundo desde la medianoche (00:00:00.0000000 UTC) del 1 de enero de 1601 en el calendario gregoriano proleptico como un entero con signo de 64 bits. Este valor se desbordará el 14  de septiembre de 30.828 a las 02:48:05  UTC, después de lo cual Windows ya no podrá aceptar fechas y mostrará errores de "hora del sistema no válida". ^{[ 5 ] [ 94 ]}

De manera similar, los GETCURRENTTICKSSTATICcomandos en Cosmos DB devuelven el número de ticks de 100 nanosegundos desde la época Unix de medianoche (00:00:00.0000000  UTC) del 1  de enero de 1970, ^{[ 95 ]} que se reiniciará el 14  de septiembre de 31197 a las 02:48:05. ^{[ 96 ]}

Los programas que procesan años como valores de 16 bits pueden encontrar problemas al tratar con el año 32.768 o el 65.536, dependiendo de si el valor se trata como un entero con signo o sin signo.

Para sistemas que utilizan enteros con signo de 16 bits, los años posteriores a 32.767 pueden interpretarse como números negativos, ^{[ 5 ] [ 97 ]} comenzando con −32.768 que puede mostrarse como 32.768 a. C. En sistemas que utilizan enteros sin signo de 16 bits, es más probable que el problema se manifieste cuando el año 65.536 aparece como año 0, ^{[ 5 ] [ 98 ]} o cuando el año 65.537 vuelve al año 1. 

Los archivos de bibliotecas estáticas creados mediante el arcomando Unix almacenan marcas de tiempo como una cadena ASCII que contiene un número decimal de segundos transcurridos desde la época Unix , con un límite de 12 caracteres ASCII. Este valor se reiniciará a las 01:46:40  UTC del 27 de  septiembre de 33.658, un billón de segundos después de la época Unix. ^{[ 5 ]}

El año 100.000 será el primer año gregoriano con seis dígitos.

La API de fechas de JavaScript almacena las fechas como el número de milisegundos transcurridos desde el 1  de enero de 1970. Las fechas tienen un rango de ±100.000.000  días desde la época, lo que significa que los programas escritos en JavaScript que utilizan la API de fechas no pueden almacenar fechas posteriores al 13  de septiembre del año  275.760 d. C. ^{[ 5 ] [ 99 ]}

Los sistemas que almacenan la hora Unix en segundos usando enteros con signo de 64 bits pueden representar fechas y horas hasta las 15:30:08  UTC del domingo 4  de diciembre del año  292.277.026.596 d. C. ^{[ 5 ] [ 100 ] [ 101 ]} Sin embargo, este año está tan lejos en el futuro (mucho más allá de la probable vida útil de la Tierra , el Sol e incluso más allá de algunas predicciones de 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 las versiones anteriores, como el problema del año 2038, no pueden ser verdaderamente "resueltas" para siempre.

Además, en el caso de años históricos, podrían surgir problemas al gestionar eventos históricos, por ejemplo:

• Problema del año 0
• Problema del año 1000
• Problema del año 1414
• Problema del año 1582
• Problema del año 1900

• Heisenbug : error de software que parece cambiar al depurar. 
• Fundación Long Now – organización estadounidense sin fines de lucro