Herramientas de desarrollo · Convertidor de marca de tiempo Unix
No todas las épocas son 1970: fechas NTP, Windows FILETIME, GPS y Excel
· Antecedentes
marcas de tiempo formatos de datos depuración
El origen 1970 de Unix es sólo uno de muchos. Esta publicación examina las épocas que encontrará en archivos y protocolos (1900, 1601, 1904, 1980, 2001) y muestra cómo reconocer un valor que nunca fue tiempo de Unix.
La marca de tiempo que llegó a 1900: un valor de una captura de red que ninguna elección de unidad podría hacer sensata
Un número de una captura de paquete puede producir tonterías tanto en segundos como en milisegundos porque la unidad no es el único parámetro oculto. Época significa un punto cero elegido; Unix usa 1970, mientras que otro protocolo puede contar desde otro lugar. El cambio de escala no puede reparar el origen incorrecto.
Cuando ambas lecturas de ToolAcre entren en conflicto con el tiempo del evento conocido, deje de alternar. Identifique el nombre del campo, productor, versión del protocolo y origen documentado. Recortar dígitos repetidamente hasta que aparezca un año plausible convierte la investigación en una coincidencia.
El mismo diagnóstico se aplica cuando aparece una fecha sensata pero entra en conflicto con los eventos circundantes. La plausibilidad es un control débil; la procedencia y un evento de referencia conocido son más fuertes.
NTP y 1900 — segundos desde 1900-01-01 con una fracción de 32 bits y la reinversión 2036 que trae
El libro de trabajo proporcionó el origen de NTP, el diseño fraccionario y la fecha de renovación. Ninguno está implementado ni probado en el convertidor de Unix, por lo que este artículo no certifica esos detalles. Una captura de red debe decodificarse de acuerdo con la documentación del protocolo utilizada por el remitente y el analizador.
Solo después de derivar los segundos de Unix el valor debe ingresar a esta herramienta. Mantenga la era o el contexto de sustitución porque es posible que un campo de ancho fijo no lo identifique por sí solo. Un resultado UTC pulido de una era supuesta puede ser internamente consistente y externamente incorrecto.
Los campos de protocolo también pueden dividir componentes enteros y fraccionarios. Concatenarlos o decimalizarlos sin la escala especificada crea un nuevo número que ningún decodificador compatible pretendía.
Los detalles de conversión NTP y el comportamiento de transferencia requieren documentación fuente que no está presente aquí
Asimismo, los contadores nombrados de Windows y .NET no son modos aceptados. El repositorio no contiene constantes para sus orígenes o escalas de ticks. Sus valores decimales grandes pueden exceder el rango entero exacto de JavaScript antes de que un desarrollador intente la conversión.
Utilice una biblioteca segura para enteros basada en la definición documentada de la plataforma, conserve el original como texto o entero ancho y luego emita un valor Unix. No reste un desplazamiento recordado en punto flotante. La exactitud en el extremo inferior es importante cuando la resolución de la fuente es inferior a milisegundos.
Una prueba de ida y vuelta debe incluir un valor con dígitos inferiores a cero. Los dispositivos de segundos completos no pueden exponer si el resto de 100 nanosegundos o milisegundos se conservó correctamente.
Las definiciones FILETIME y .NET no las implementa ToolAcre y no se afirman desde la memoria
Las fechas de la hoja de cálculo introducen una representación diferente: una serie numérica interpretada por la configuración del sistema de fechas del libro. La peculiaridad 1900 del libro de trabajo y la afirmación de Mac anterior requieren fuentes de hojas de cálculo y no se establecen aquí. ToolAcre no lee los metadatos del libro de trabajo.
Inspeccione el archivo con herramientas compatibles con hojas de cálculo, determine el sistema de fechas configurado y conserve la precisión de fracciones de día utilizando esa biblioteca. Tratar una serie como segundos de Unix puede producir una fecha temprana-1970 que parece un error de escala normal, mientras que el problema real es el origen y la unidad juntos.
La configuración del libro de trabajo puede viajar con un archivo, por lo que dos publicaciones seriadas visualmente similares pueden usar orígenes diferentes. La conversión pertenece al límite del documento donde esos metadatos están disponibles.
Los sistemas seriales de hojas de cálculo y sus peculiaridades requieren evidencia específica de la hoja de cálculo
Las épocas relacionadas con GPS y Apple mencionadas en el esquema también están fuera de la implementación. Sus relaciones pueden implicar convenciones de escala más allá de un cambio constante de origen. Aquí no se publica ninguna fórmula de compensación o conversión actual sin evidencia autorizada.
El diagnóstico general aún se transfiere: identificar cero, duración del tick y convención de salto del productor. Luego, convierta con una biblioteca adecuada y verifique con una marca de tiempo conocida del mismo conjunto de datos. Tres hechos independientes son más seguros que una suposición del ancho de un decimal.
Esa precaución es particularmente importante en torno a las convenciones de salto. Una constante que funcione para una escala y fecha puede no ser una relación eterna entre cada par de sistemas.
Las relaciones de época de GPS y Apple requieren fuentes autorizadas fuera de este módulo
Un método trabajado defendible comienza con un instante conocido, por ejemplo, el `2025-02-03T10:23:00.000Z` verificado por ToolAcre, igual a 1,738,578,180 segundos Unix. Para otra época documentada, calcule su valor usando el origen oficial de ese sistema y escale con aritmética de enteros, luego conviértalo nuevamente usando la misma definición.
Compare el viaje de ida y vuelta con la cadena ISO de Unix y conserve la derivación. Este artículo no llena intencionalmente una tabla de cinco épocas con constantes que no se leyeron. El método expone todas las suposiciones y puede revisarse con respecto a cualquier protocolo o formato de archivo que realmente haya producido los datos.
Método trabajado: derivar un instante a través de épocas documentadas en lugar de publicar constantes no verificadas
ToolAcre no reconoce ni convierte automáticamente épocas extranjeras. Su menú de unidades dice segundos y milisegundos, ambos según la definición de Unix en la configuración. La detección automática solo elige entre aquellas escalas de magnitud 10¹¹; nunca cambia el punto cero.
Ese contrato restringido evita la falsa confianza. Si un recuento extranjero llega a una fecha Unix plausible, el convertidor no puede advertir que el origen era incorrecto. La procedencia debe entrar antes que la aritmética. Documente la transformación en código en lugar de depender de un runbook manual.
La etiqueta automática visible solo informa segundos o milisegundos. Nunca debe citarse como prueba de que se produjo la detección del origen, porque tal rama no existe en la fuente.
Conclusión: sepa desde qué cero está contando y cómo el conversor de marcas de tiempo de Unix le dice claramente que lee segundos o milisegundos de Unix.
Sepa desde qué cero está contando, qué tan grande es un tick y cómo la fuente maneja su escala de tiempo. Un convertidor de Unix responde solo después de que esas preguntas se resuelvan en segundos o milisegundos desde 1970 UTC. No puede inferir semántica a partir de un número entero.
Utilice lecturas duales inverosímiles como señal para investigar el origen, no como permiso para seguir probando divisores. Una vez que una conversión de origen produce un valor Unix, ToolAcre proporciona una útil verificación independiente de UTC y de cordura local mientras mantiene visible su propia suposición.
Un buen adaptador nombra el tipo externo, realiza una transformación de origen y emite un valor Unix de marca. Ese diseño evita que los contadores sin procesar se filtren en constructores de fechas genéricos.