Herramientas de desarrollo · Convertidor de marca de tiempo Unix
El problema del año 2038: ¿qué sucede cuando 32-bit time_t se desborda?
· Antecedentes
marcas de tiempo tiempo Unix depuración
El 19 de enero del 2038 a las 03:14:07 UTC, un contador de segundos de 32 bits firmado pasa a 1901. Esta publicación explica la aritmética, dónde aún se esconde el tiempo de 32 bits y cómo reconocer un sistema que se verá afectado.
Una fecha que está más cerca de lo que parece: las hipotecas, los certificados y el firmware ya calculan fechas posteriores al 2038
Un límite con fecha 2038 afecta al código siempre que calcula una fecha límite de vencimiento, programación o retención más allá de ese punto. Por tanto, el fallo puede aparecer años antes de la fecha del reloj. Este repositorio no documenta productos hipotecarios, certificados o firmware, por lo que esos ejemplos no se presentan como casos observados.
La pregunta práctica de auditoría es si algún límite almacena segundos de Unix en un entero de 32 bits con signo. Un navegador moderno que formatea con éxito una fecha futura no dice nada sobre un campo más estrecho en sentido descendente. Rastree la serialización y la persistencia, no solo la interfaz de usuario.
Busque cálculos de fechas futuras en las pruebas de hoy en lugar de esperar un reloj de producción. Un límite fijo convierte una preocupación de calendario distante en una verificación inmediata y repetible.
Los cálculos de fechas futuras pueden exponer límites de 32 bits antes de 2038, pero las industrias mencionadas no se muestran aquí
El máximo de un entero de 32 bits con signo es 2³¹−1 o 2,147,483,647. Las pruebas establecen que muchos segundos después de la época `2038-01-19T03:14:07.000Z`. Un segundo matemático más debería ser 03:14:08, y ToolAcre lo muestra porque el número y la fecha de JavaScript pueden llevar el valor.
Ajustar a un valor negativo requiere una operación externa de 32 bits con firma; `fromEpoch` no realiza ninguno. El resultado del 1901 de diciembre, frecuentemente citado, se puede derivar para el ajuste en complemento a dos, pero afirmar que cada sistema afectado ajusta en lugar de rechazar, satura o corrompe excedería la evidencia. Pruebe el límite real.
Si una conversión externa pasa por la aritmética en complemento a dos, inspeccione los bits almacenados resultantes y el valor negativo decodificado. No infieras la conclusión únicamente a partir de una fecha histórica inesperada.
Se verifica el instante superior exacto; El comportamiento de ajuste depende de la operación entera externa.
Esquemas de búsqueda, definiciones de protocolos y diseños binarios para campos firmados de 32 bits que contienen segundos de época. Una columna SQL denominada INTEGER no es prueba suficiente en todos los motores y una plataforma integrada no se ve afectada automáticamente. Determine el ancho, el signo, la unidad y el código de conversión para cada ruta.
Incluir archivos y registros almacenados en caché en la auditoría. Un tipo en memoria ampliado aún puede escribir un formato estrecho antiguo, mientras que una base de datos amplia puede recibir un valor de cliente truncado. Cree accesorios al máximo y uno más allá, luego inspeccione los bytes o el valor persistente en lugar de simplemente verificar que una función haya tenido éxito.
Localice campos de época de 32 bits firmados inspeccionando esquemas y formatos reales
La solución conceptual es una representación cuyo rango incluye fechas requeridas, comúnmente un recuento con signo más amplio o un tipo temporal apropiado. La narrativa de migración de formato, libc y kernel del libro de trabajo está fuera de estos archivos fuente. Cada sistema tiene su propio trabajo de compatibilidad e implementación.
Ampliar cada límite como un cambio de contrato coordinado. Actualizar el almacenamiento sin un campo de cables o una biblioteca sin datos existentes deja un vínculo estrecho. Agregue versiones cuando sea necesario y pruebe los lectores antiguos de forma explícita. No es necesario cambiar la definición de época en sí; el contenedor lo hace.
La planificación de la migración debe incluir un comportamiento de reversión y versión mixta. Un escritor nuevo que produce valores amplios puede romper a un lector antiguo antes de que cualquier fecha persistente alcance el límite del calendario.
Ampliar la representación es la solución principal; Las migraciones de kernel y formato son específicas del sistema.
Convierta 2,147,483,647 en segundos para obtener `2038-01-19T03:14:07.000Z`; convierta 2,147,483,648 para obtener `2038-01-19T03:14:08.000Z`. El suave paso de un segundo demuestra que la ruta ToolAcre no tiene un acantilado de 32 bits en ese valor.
Ahora fuerce los mismos números que milisegundos. Caen en enero 1970 porque los valores llegan a ser aproximadamente veinticinco días después de cero. Esa comparación evita que un error de unidad sea mal etiquetado como problema 2038. El ancho del campo y la escala son dimensiones independientes.
Esta comparación también demuestra por qué un convertidor es diagnóstico en lugar de vulnerable: la selección explícita de unidades determina la escala, mientras que la representación más amplia del navegador incluye ambos valores.
Ejemplo resuelto: el convertidor cruza el límite porque la fecha de JavaScript no está firmada 32-bit segundos
El repositorio también prueba 4,294,967,295 segundos como `2106-02-07T06:28:15.000Z`, el recuento máximo de 32 bits sin firmar. No prueba un desplazamiento semanal del GPS ni especifica un acantilado de milisegundos de 64 bits firmado, por lo que los temas nombrados se omiten en lugar de generalizarse.
El análisis de límites debe seguir el tipo exacto en uso. Cambiar de firmado a sin firmar se extiende en una dirección pero elimina las fechas negativas y aún crea un borde superior. Una representación firmada más amplia generalmente conserva ambas direcciones, sujeta al rango de fechas del consumidor.
Cada acantilado necesita su propia derivación de ancho, signo y unidad. Agrupar rollovers no relacionados bajo “2038” oculta qué campo binario realmente requiere cambio.
Se prueba el límite de 32 bits sin firmar; otros acantilados con nombre están fuera del depósito de evidencia
Un convertidor no puede auditar el código fuente, los archivos binarios, los esquemas de bases de datos ni los dispositivos implementados. Muestra lo que significa un número de candidato y proporciona elementos concretos para las pruebas. La búsqueda estática, la inspección de tipo, las pruebas de serialización y los ensayos de migración deben establecer si un producto es seguro.
No cierre una auditoría porque el navegador muestra 2038 correctamente. Eso solo verifica la ruta de este navegador. Siga el valor de principio a fin, especialmente a través de enlaces de idiomas y formatos antiguos donde puede ocurrir una restricción implícita.
Incluya las interfaces de dependencia y proveedor en ese seguimiento. La fuente de la aplicación puede utilizar un tipo amplio, mientras que una biblioteca nativa o un protocolo de dispositivo reduce el mismo valor de forma invisible.
Conclusión: la época está bien, el ancho del entero es el problema y cómo el conversor de marcas de tiempo de Unix le permite verificar cualquier valor de límite en UTC y hora local
El problema del año 2038 es un límite de ancho de entero, no un defecto en la aritmética de la época de Unix. La conversión exitosa de ToolAcre en ambos lados hace visible esa separación. El sistema externo falla sólo si una de sus representaciones no puede llevar el siguiente conteo.
Utilice 2,147,483,647 y 2,147,483,648 como vectores de prueba adyacentes, verifique la persistencia exacta y documente la unidad y la firma. La evidencia en todos los límites es más valiosa que una lista genérica de tecnologías supuestamente vulnerables.
Los vectores adyacentes deben cruzar una ruta de serialización real, no solo un cálculo en memoria. Ahí es donde una aplicación nominalmente ampliada puede revelar una costura estrecha restante.