Herramientas de desarrollo · Convertidor de marca de tiempo Unix
Segundos bisiestos y tiempo Unix: por qué la época finge que no existen
· Antecedentes
marcas de tiempo tiempo Unix zonas horarias
UTC ha insertado segundos intercalares desde 1972, pero el tiempo de Unix simplemente no los cuenta, lo que significa que algunos segundos han pasado dos veces. Esta publicación explica por qué, qué es el manchado y por qué está previsto que termine toda la práctica.
El segundo ocurrió dos veces: un 23:59:60 en un sistema, un 23:59:59 repetido en otro y un error de clave duplicada a medianoche.
ToolAcre no puede producir una fila ISO que termine en `23:59:60`. Su prueba nombra el límite del segundo intercalar y espera que un valor de época se formatee como `2016-12-31T23:59:59.000Z` y el siguiente como `2017-01-01T00:00:00.000Z`. No hay ningún segundo adicional visualizable entre ellos.
Ese hecho puede afectar los registros cuya fuente externa utilizó otra convención, pero este repositorio no contiene evidencia de incidentes con claves duplicadas. Si aparecen etiquetas repetidas en un sistema, inspeccione ese reloj y ruta de almacenamiento en lugar de atribuirlas automáticamente al convertidor.
Por lo tanto, un sistema que requiere una etiqueta única para cada segundo físico necesita más contexto que este mapeo de Unix hasta la fecha. El convertidor no puede fabricar una etiqueta que omita su modelo.
ToolAcre demuestra que no es representable 23:59:60; no documenta incidentes con claves duplicadas
El esquema explicaba el tiempo atómico, la rotación de la Tierra y un umbral de tolerancia. Esas afirmaciones científicas y estándar no están establecidas por el código de marca de tiempo ni por las pruebas. Se omiten intencionalmente en lugar de parafrasearse de memoria. El mecanismo aquí no prueba las razones detrás de la política global de cronometraje.
Para usar esta ruta, la evidencia necesaria es más simple: la fecha y la salida ISO exponen segundas etiquetas ordinarias, y la época de estilo POSIX avanza a través del límite probado. Un tratamiento basado en fuentes de la gobernanza de segundo intercalar requeriría material autorizado más allá de las rutas de repositorio permitidas.
Este límite es explícito en lugar de evasivo: las pruebas de software responden preguntas de representación, mientras que la historia científica necesita material escrito para ese propósito y revisado en sus propios términos.
La justificación física de los segundos intercalares requiere fuentes fuera de este repositorio
El modelo implementado se comporta como si los días civiles en su eje tuvieran 86,400 segundos Unix numerados. Las entradas de números enteros consecutivos difieren en un segundo, incluso a lo largo del límite del año 2016. `fromEpoch` multiplica cada uno por 1,000 y la fecha formatea el recuento de milisegundos resultante.
Llamar a esto “ignorar” segundos intercalares describe un resultado observable: ningún valor Unix único se asigna a una etiqueta `:60`. No implica que todos los relojes de las máquinas avancen de manera idéntica durante una inserción real. El convertidor acepta un conteo; no muestrea ni disciplina el reloj del host.
La aritmética en rangos más grandes sigue la misma convención, por lo que restar dos valores de Unix mide su diferencia de recuento de estilo POSIX en lugar de reconstruir etiquetas de salto omitidas.
La conversión probada no tiene una etiqueta de segundo intercalar entre valores de época consecutivos.
Los sistemas pueden aplicar pasos, repeticiones o calumnias, pero el repositorio no identifica qué proveedores utilizan qué método, en qué intervalo o con qué fórmula. Publicar esos detalles sin evidencia directa crearía una precisión operativamente peligrosa. Por lo tanto, este artículo no hace ninguna promesa de reloj específica de la plataforma.
Si los eventos cercanos a un límite de salto son importantes, conserve la documentación del reloj de la fuente y los valores sin procesar. Dos sistemas con manejo diferente pueden no coincidir incluso después de que ambos valores tengan el formato UTC. La conversión por sí sola no puede conciliar su comportamiento de muestreo ni recuperar una distinción de escala omitida.
La elección de un tiempo de ejecución también puede afectar el orden de corta duración alrededor del evento. Conserve los contadores monótonos o los datos de secuencia específicos de la fuente cuando esa distinción sea importante desde el punto de vista operativo.
El comportamiento del paso del reloj y de la difamación es específico de la plataforma y no se verifica aquí
Ingrese 1,483,228,799 segundos: el resultado ISO verificado es `2016-12-31T23:59:59.000Z`. Incremente la entrada una vez a 1,483,228,800: el resultado es `2017-01-01T00:00:00.000Z`. Restar los números enteros da uno, que coincide con la progresión mostrada en este modelo.
Las filas locales pueden mostrar diferentes fechas o desplazamientos según el navegador, pero derivan de esos mismos instantes. Utilice las filas ISO para la verificación de límites. Un cambio de zona local no está relacionado con la existencia de una etiqueta de segundo intercalar.
El par es una prueba de regresión útil porque no hay dependencia regional en las cadenas ISO. Bloquea directamente el comportamiento del convertidor en el borde relevante.
Ejemplo resuelto: el límite 2016 probado del repositorio
El libro de trabajo hacía referencia a una resolución 2022 y una fecha límite futura. Ninguna fuente de estándares o políticas forma parte de la evidencia de implementación, por lo que aquí no se afirma ni la fecha ni el pronóstico. La política de cronometraje puede cambiar y merece una cita autorizada actualizada en el momento de la publicación.
Omitir esa afirmación no debilita la guía de software. Los datos existentes aún necesitan documentar su escala, unidad y fuente de reloj. El comportamiento actual de un convertidor sigue siendo comprobable independientemente de las decisiones sobre las prácticas futuras en tiempo civil.
Los mantenedores pueden agregar contexto de política más adelante citando la resolución directamente. Hasta entonces, excluir una fecha límite es más exacto que publicar una garantía futura sin respaldo.
Se omiten las resoluciones de políticas futuras sin una fuente autorizada
TAI, GPS y otras escalas pueden representar el tiempo de manera diferente, pero ToolAcre no ofrece ningún selector ni tabla de compensación para ellas. Pegar un recuento como segundos de Unix simplemente aplica la interpretación de estilo 1970 POSIX. Un resultado legible aún puede ser semánticamente incorrecto.
Transforme otras escalas con una fuente que defina su origen y relación en el instante relevante, luego inspeccione el valor Unix resultante. No agregue una constante recordada: las relaciones que involucran la historia de saltos son exactamente donde la aritmética sin fuente se vuelve frágil.
La ausencia de un modo es visible en las tres opciones de unidad de la interfaz de usuario. Ninguno cambia la escala de tiempo; automático simplemente selecciona entre dos resoluciones Unix.
Otras escalas de tiempo están fuera de la implementación de este convertidor Unix
Para este convertidor, la regla verificada es un paso directo de 23:59:59 a 00:00:00 en el límite probado. Ese modelo admite la aritmética de época ordinaria y explica por qué no aparece ninguna salida `:60`. No certifica cómo se comportó el reloj del sistema operativo mientras pasaba el límite real.
Cuando la precisión en el manejo de saltos es importante, la conversión es el último paso de la presentación, no la fuente de evidencia. Primero recopile la documentación a escala de reloj, el comportamiento de sincronización y los campos de eventos sin procesar. ToolAcre puede luego mostrar qué significa un recuento de Unix declarado según su modelo probado.
Para registros ordinarios alejados de los límites de salto, este matiz rara vez cambia de visualización. Sin embargo, cerca de límites sensibles, nombrar el modelo evita afirmaciones falsas de segunda fidelidad física.