Segundos transcurridos desde la época

 (aphyr.com)
2 puntos por GN⁺ 2024-12-27 | 1 comentarios | Compartir por WhatsApp
  • El tiempo POSIX/Unix suele describirse como la cantidad de segundos desde 1970-01-01 00:00:00, pero en realidad es un valor basado en UTC que ignora los segundos intercalares, por lo que no coincide con los segundos reales transcurridos
  • A la fecha 2024-12-25 18:51:26 UTC, el tiempo POSIX es 1735152686 y los segundos reales transcurridos desde la época son 1735152713, una diferencia de 27 segundos
  • IEEE 1003.1 define seconds since the Epoch calculando siempre un día como 86,400 segundos, y el apéndice del estándar también ignora los 14 segundos intercalares añadidos desde 1970 por compatibilidad y facilidad de cálculo
  • UTC añade segundos intercalares para reducir la diferencia con el día solar, y en esos momentos el tiempo POSIX puede saltar hacia atrás, lo que ha causado incidentes en Linux, Qantas y Cloudflare DNS
  • Para medir intervalos de tiempo en una sola computadora, conviene más usar CLOCK_MONOTONIC o CLOCK_BOOTTIME; si hace falta alinearse con timestamps POSIX, hay que considerar leap smear o la conversión POSIX↔TAI

El tiempo POSIX no es la cantidad real de segundos transcurridos

  • JavaScript Date, GNU coreutils, Linux time(2), Go time.Unix, MySQL datetime, Ruby Time, Cassandra timestamp y otros suelen tratar el tiempo POSIX como si fuera la cantidad de segundos desde la época Unix
  • Pero esa expresión no coincide exactamente con la intuición general ni con la precisión real
    • Ejemplo de fecha y hora: 2024-12-25 18:51:26 UTC
    • Tiempo POSIX: 1735152686
    • Segundos reales transcurridos desde la época POSIX: 1735152713
    • Diferencia: 27 segundos
  • Esta diferencia existe porque el tiempo POSIX se deriva de UTC en IEEE 1003.1, pero asume que todos los días tienen exactamente 86,400 segundos
  • La definición del estándar para seconds since the Epoch calcula el valor usando tm_sec, tm_min, tm_hour, tm_yday y tm_year, y no define su relación con años menores a 1970 ni con valores negativos
  • La duración real de un día no siempre es de 86,400 segundos y puede variar con el tiempo
    • Los astrónomos declaran periódicamente segundos intercalares para que la fecha UTC no se aleje demasiado del día solar
    • Como resultado, el tiempo POSIX puede saltar hacia atrás cada ciertos años
    • Algún día también podría saltar hacia adelante
  • Los segundos intercalares ya han provocado fallas reales

El compromiso del estándar y alternativas prácticas

  • El apéndice B de IEEE 1003 resume que, al momento de publicarse el estándar, se habían añadido 14 segundos intercalares desde 1970-01-01, pero esos 14 segundos se ignoran para simplificar los cálculos y mantener la compatibilidad
  • El estándar asume que el valor de “time” en la mayoría de los sistemas sigue aumentando, y opta por exigir que también aumente durante un segundo intercalar
    • Al mismo tiempo, parte de la base de que la mayoría de los sistemas no rastrean segundos intercalares ni necesariamente están sincronizados con un estándar horario oficial
    • Por eso no exige que seconds since the Epoch represente obligatoriamente la cantidad exacta de segundos entre la época y el instante de referencia
    • Basta con que las aplicaciones puedan tratar ese valor como si fuera una cantidad de segundos desde la época; la precisión necesaria queda en manos del proveedor y del administrador del sistema
  • En aplicaciones distribuidas, los eventos se sincronizan con timestamps, así que una interpretación consistente puede volverse importante
    • La acumulación de segundos intercalares no puede predecirse
    • La cantidad de segundos intercalares desde la época podría seguir aumentando
    • El estándar se enfoca más en la sincronización temporal entre aplicaciones durante periodos astronómicamente cortos
  • En la práctica, los sistemas suelen seguir funcionando aunque la hora esté un poco desfasada, pero como los segundos intercalares son raros y la intuición lineal de “segundos desde la época” es fuerte, pueden acumularse bugs que pasen desapercibidos
  • Las alternativas según el caso son las siguientes
    • Si solo necesitas calcular la duración entre dos eventos en una misma computadora, usa CLOCK_MONOTONIC o, mejor aún, CLOCK_BOOTTIME
    • Si no necesitas intercambiar timestamps con otros sistemas que asumen tiempo POSIX, usa TAI, GPS o LORAN
    • Si necesitas aproximarte a sistemas basados en timestamps POSIX, distribuye el segundo intercalar en un periodo más largo con leap smear
    • Con bibliotecas como t-a-i de qntm es posible convertir entre POSIX y TAI
  • Hay esfuerzos para abolir los segundos intercalares, con la expectativa de lograrlo para 2035
    • Eso requerirá trabajo adicional para incorporar tablas de conversión en todo lo que dependa del supuesto de un día = 86,400 segundos
    • Para fechas posteriores a 2035, preguntas como “¿cuántos segundos hay entre dos momentos?” podrían volverse mucho más simples

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-12-27
Opiniones de Hacker News

  • Acabo de leer la novela de ciencia ficción de Vernor Vinge de 2000, A Deepness in the Sky, un libro excelente que incluye una mención inesperada a los segundos desde la época (seconds since the epoch).
    Empieza con “Vean cómo miden el tiempo los Traders…”, y describe que los Qeng Ho cuentan en segundos desde el momento en que la humanidad pisó por primera vez la Luna de la Vieja Tierra, pero que, al mirar más de cerca, el punto de inicio en realidad era unos 15 millones de segundos después: el segundo cero de uno de los primeros sistemas operativos de computadora de la humanidad.

    • Este libro es, personalmente, uno de mis favoritos de todos los tiempos, y me encanta cómo usa referencias sutiles al software.
      Si quieren más “ciencias de la computación en el espacio”, recomiendo la serie Bobiverse; si quieren más exploración de “humanos + simulación + computadoras”, recomiendo Permutation City.

  • Cada vez que leo sobre medición del tiempo, inevitablemente aprendo algo nuevo. Siempre pensé que el tiempo Unix era la forma más simple de llevar registro del tiempo, considerando solo el rollover, y aunque conocía los segundos intercalares, no se me había ocurrido que también aplicaran aquí.
    También leí el enlace “UTC, GPS, LORAN and TAI”, y resulta interesante el contraste de que el tiempo GPS no refleja los segundos intercalares.

    • Decir que algo ocurrió tantos segundos antes/después es simple. Lo difícil es asignarle a ese instante una fecha de calendario.
    • En conclusión, termino viendo a TAI como lo más simple, y los demás formatos deberían convertirse desde TAI solo cuando haga falta. Por ejemplo, para visualización o interoperabilidad.

  • No me convence el plan de que “hay esfuerzos en curso para eliminar los segundos intercalares para 2035”.
    El punto central de UTC es estar separado de TAI por un número entero de segundos y aproximarse al tiempo solar medio (MST). Si ya no se va a seguir el MST, simplemente habría que cambiarse a TAI.
    Si se deja que UTC se aleje del MST, queda en un estado ambiguo en el que los segundos intercalares del pasado siguen teniendo que manejarse, pero ya no tienen propósito.

    • Estoy de acuerdo en que apartarse del MST cuesta más de lo que aporta.
      Dicho eso, la propuesta no es completamente inútil. Su objetivo es no cambiar la gestión actual del tiempo UTC y, al mismo tiempo, lograr que la diferencia entre dos marcas de tiempo posteriores a 2035 sea la cantidad exacta de segundos físicos.
      Aun así, como el MST ya es una función de UTC, eliminarlo parece absurdo.
    • En un mundo ideal, los sistemas informáticos habrían usado TAI para registrar el tiempo y la base de datos TZ para convertir a UTC o a hora local.
      Pero en la realidad, muchos sistemas tomaron malas decisiones, y UNIX en particular es el mayor responsable. Esa decisión está tan profundamente incrustada en innumerables sistemas y regulaciones que “simplemente pasarse a TAI” es prácticamente imposible.
      Por eso es más fácil reinterpretar UTC como el “nuevo TAI”. No me sorprendería que algún día el antiguo UTC reaparezca con otro nombre.
    • No existe una entidad separada llamada TAI. TAI es lo que se obtiene al partir de UTC y restarle la cantidad de segundos intercalares que importan. TAI no se mantiene como una cantidad estándar separada.
      En la mayoría de los países, o en todos, la hora civil se basa en UTC. No se van a atrasar los relojes de todo el mundo unos 30 segundos solo porque sea un poco más puro.
      El tiempo GPS también tiene un desfase respecto de TAI y a nadie le importa demasiado. Lo mismo pasa con la época Unix: basta con que el resultado sea consistente.
    • El hack es literalmente trivial. Una vez al mes se revisa si UTC # ET, y si no coincide, se crea un archivo llamado Leap_Second. Cada mes se mira si ese archivo existe; si existe, se borra, se suma 1 al valor del archivo Leap_Seconds y se crea una copia de respaldo llamada LSSE.
      “You are not expected to understand this.” Es una forma de mantener ambos sistemas. Si se quiere, también se puede hacer con hashes o una tabla de consulta.

  • También es importante que la época UTC moderna sea el 1 de enero de 1972. Antes de eso, UTC usaba una duración de segundo distinta de la de TAI.
    A fines de 1971 hubo, como paso intermedio, el último salto irregular de exactamente 0.107758 segundos TAI, y la suma de los pequeños escalones de tiempo y ajustes de frecuencia de UTC o TAI entre 1958 y 1971 se ajustó para que fuera exactamente de 10 segundos. Así, el 1 de enero de 1972 a las 00:00:00 UTC fue exactamente el 1 de enero de 1972 a las 00:00:10 TAI, y desde entonces la diferencia es de un número entero de segundos.
    Al mismo tiempo, la frecuencia de ticks de UTC pasó a ser exactamente igual a la de TAI, y UTC empezó a seguir UT1 en lugar de UT2. Por lo tanto, el tiempo Unix de 1970 y 1971 no coincide con el tiempo UTC real de ese período.
    https://en.wikipedia.org/wiki/Coordinated_Universal_Time#His...
    https://en.wikipedia.org/wiki/Unix_time#UTC_basis

    • Por eso, entre las personas vivas hoy hay algunas que no pueden saber su edad exacta (en segundos), ni podrán saberla en el futuro.
      Incluso suponiendo que la hora en su acta de nacimiento sea precisa al segundo. Esto se debe a que, durante parte de su vida, el valor considerado como “la duración de un segundo” era bastante distinto del segundo que normalmente entendemos hoy.
      Aquí, “segundo” se refiere al segundo definido por la frecuencia de transición hiperfina del estado fundamental no perturbado del átomo de cesio-133, de 9,192,631,770/s.

  • Hace poco escribí código para cierto exchange, y ese sistema corría sobre VAX o, más precisamente, sobre OpenVMS, y su epoch era el 17 de noviembre de 1858.
    Fue la primera vez en mi carrera que vi un epoch que no fuera Unix y, por suerte, en el código que usábamos estaba abstraído al epoch de Unix.

    • El epoch de 1858 parece venir del Julian Day, el calendario estándar de la astronomía. Ahí, el día 0 es el año 4713 a. C.
      https://www.slac.stanford.edu/~rkj/crazytime.txt
      Para que estas fechas cupieran en la memoria de las computadoras de los años 50, desplazaron el calendario en 2,4 millones de días, y como resultado el día 0 quedó en el 17 de noviembre de 1858.
    • También hay una vieja anécdota de Microsoft sobre el choque entre el epoch de Excel, el 1 de enero de 1900, y el de Basic, el 31 de diciembre de 1899.
      https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
    • Otro sistema de cómputo común que vale la pena conocer: el epoch de Windows es el 1 de enero de 1601.
    • Classic MacOS, el sistema de archivos HFS de Apple (también usado en OS X) y PalmOS tenían todos como epoch el 1 de enero de 1904.
      La API Foundation de macOS/Swift NSDate.timeIntervalSinceReferenceDate usa como epoch el 1 de enero de 2001.
      Wikipedia también tiene una lista útil: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...
    • PostgreSQL usa internamente el epoch 2000-01-01 para almacenar timestamps.

  • Algunos instantes no pueden representarse como timestamp POSIX, y algunos timestamps POSIX no corresponden a un tiempo real.

    • Me pregunto cuáles son los timestamps POSIX que no corresponden a un tiempo real. ¿O se refiere a si en el futuro hubiera un segundo intercalar negativo?
    • Esto siempre fue así. En el tiempo Unix, lo anterior a 1970 no está definido.
    • Aun así, al menos ningún timestamp POSIX corresponde a dos o más instantes reales. Es mejor que usar una única representación para todo, como hace todo el mundo.
    • No es así.
      Eso es parecido a decir que hay instantes que no tienen año ISO 8601. Todos los instantes tienen año; solo que algunos años son más largos que otros.
      Si te sientas a mirar https://time.is/UTC, el tiempo aumentará de forma monótona, y de vez en cuando algún segundo será apenas un poco más largo. Por ejemplo, algo así como un 0,001% más largo durante 24 horas.

  • Al guardar fechas en una base de datos, siempre las guardo como tiempo Unix epoch, y no registro información de zona horaria en el campo de fecha. Si hay un requisito de conocer la zona horaria, la guardo por separado.
    Me pregunto si, en cambio, debería guardar los timestamps en formato TAI y usar una función que los convierta a UTC cuando haga falta, de modo que pueda manejar correcciones relacionadas con la Tierra cuando sean necesarias.
    Sé que las zonas horarias son un campo minado, pero eso también es una construcción humana cuyas fronteras cambian con el tiempo. Me parece que habría que fijarlo a tiempo absoluto y luego renderizarlo en el formato de hora local deseado cuando haga falta.

    • Correcto. TAI o un formato similar es la única forma razonable de llevar el tiempo “del sistema”, y los sistemas de más alto nivel deberían convertirlo a tiempo legible para humanos.
      Los ajustes por segundos intercalares deberían ocurrir en el mismo lugar que las conversiones de zona horaria. Por desgracia, Unix estandarizó lo incorrecto, y migrar es difícil.
    • En general no, y casi nunca. La mayoría del software está escrito para absorber los segundos intercalares, y en la práctica solo ocurren en la capa de sincronización de relojes. Por ejemplo, chrony implementa el suavizado de segundos intercalares.
      Por lo tanto, todos los relojes están alineados con UTC de todos modos. Tendrías que convertir de UTC a TAI al guardar y volver a convertir al leer, lo que terminaría siendo un desastre.
    • Sobre lo de “no registro información de zona horaria en el campo de fecha”, en realidad hay muy pocas bases de datos que permitan preservar la zona horaria en una columna de timestamp.
      Normalmente, las bases de datos no tienen concepto de zona horaria para los timestamps almacenados (SQL Server), o bien ofrecen un tipo de timestamp “con conciencia de zona horaria” pero convierten la entrada a UTC y descartan la zona horaria original (MySQL, Postgres).
      Que yo sepa, solo Oracle puede preservar realmente en ida y vuelta una zona horaria no local en el tipo with time zone.
    • Depende de lo que guarde el sistema. A la mayoría de los sistemas no les importa equivocarse por 1 segundo cada varios años.
      En algunos cálculos, una diferencia de 1 segundo es un gran problema. Hay que tener cuidado al adoptar algo que no sea el formato más usado, y hay que tener una buena razón para apartarse del estándar. El simple hecho de ser diferente puede tener un costo alto.
    • Basta con usar los campos nativos de fecha y hora de la base de datos.

  • Este artículo siente como si me hubiera arruinado la Navidad. ¿Ya no queda nada sagrado? Los segundos deberían ser los segundos transcurridos desde el epoch.
    No entiendo por qué debería importar que se desvíe un poco del día solar. ¿No debería encargarse de la corrección el conversor que transforma los segundos desde el epoch a una representación de fecha?

    • La forma actual es, de hecho, la que queremos. 86400 segundos = 1 día, y operamos bajo el supuesto de que la medianoche UTC siempre es un múltiplo de 86400.
      No quiero que todo el software tenga que hardcodear la introducción de segundos intercalares, manejar el suavizado y requerir una forma de actualizarse dentro de un mes cada vez que se introduzca un nuevo segundo intercalar.
      Hasta ahora no hemos tenido que preocuparnos ni pensar en eso, y tampoco hace falta que lo hagamos en el futuro. Se está manejando de la forma correcta.

  • Los segundos intercalares deberían reemplazarse por cohetes gigantes montados en el ecuador. No ajustemos los relojes; ajustemos el planeta.

    • No creo que sea muy gracioso si, por un error de cálculo, la Tierra termina demasiado lenta o demasiado rápida.
      En las tradiciones islámicas sobre el fin de los tiempos y el Anticristo (Dajjal) hay una parte en la que algo así ocurre de verdad. Se dice que “el primer día del Anticristo será como un año, el segundo día como un mes y el tercero como una semana”, y muchos lo toman literalmente: un evento cósmico en el que la rotación de la Tierra realmente se ralentiza y al final se invierte, de modo que el sol sale por el oeste. Esa es la última señal del fin de la humanidad.

  • Aunque por los segundos intercalares el epoch haya quedado 29 segundos más atrás de lo que implica date +%s, no veo por qué importaría
    Es mucho más importante que todos estemos de acuerdo en algún número N que represente la hora actual. Esos -29 segundos hipotéticos no afectan al mundo real. No vamos a ejecutar una rutina de apuntado de misiles contra un objetivo de hace 30 años, ¿no?
    Estoy a favor de eliminar los segundos intercalares, pero no creo que sea útil enfatizar la discrepancia horaria. Aunque, estrictamente hablando, sea cierto

    • Puedo imaginar situaciones en las que se calcula la duración de un evento breve a partir de sus horas de inicio y fin. Si ese intervalo cruza un segundo intercalar, según cómo se procesen las marcas de tiempo, la duración puede variar bastante
      Lo más importante es el impacto en el futuro. Que una marca de tiempo del pasado pueda diferir por unos segundos de un simple cálculo de “ahora - N segundos” es, en la mayoría de los casos, más bien un dato curioso; pero que en algún momento futuro todos los relojes puedan tener que moverse otra vez 1 segundo es más importante. Hay muchos casos reales en los que tener esto en cuenta requiere bastante esfuerzo
    • Para algunas cosas sí importa. Sin esos segundos intercalares hipotéticos, por ejemplo, la posición del sol al mediodía local quedaría desfasada por 29 segundos