No se añadirá un segundo intercalar a finales de diciembre de 2026

• Según el IERS Bulletin C 72, no se añadirá un segundo intercalar al UTC a finales de diciembre de 2026, por lo que los sistemas de medición y distribución del tiempo no necesitan preparar un proceso de inserción adicional
• La diferencia entre UTC y TAI se mantiene como UTC-TAI = -37 s desde las 0:00 UTC del 1 de enero de 2017 hasta nuevo aviso
• La decisión de introducir un segundo intercalar depende de los cambios en UT1-TAI, y los momentos posibles son finales de junio o finales de diciembre
• El Bulletin C anuncia cada 6 meses un paso temporal (time step) del UTC o confirma que no habrá paso temporal en la siguiente fecha posible
• Para la distribución de UTC a finales de 2026 no se necesita un nuevo valor de corrección, y se puede seguir usando la relación existente UTC-TAI = -37 s

---

Aviso de UTC del IERS Bulletin C 72

• El IERS indicó en el Bulletin C 72, publicado en París el 6 de julio de 2026, que no se introducirá un segundo intercalar a finales de diciembre de 2026
• El aviso está dirigido a las instituciones responsables de la medición y distribución del tiempo
• Los dos valores clave son los siguientes
  • UTC-TAI = -37 s desde las 0:00 UTC del 1 de enero de 2017 hasta nuevo aviso
  • No habrá un nuevo paso temporal en UTC a finales de diciembre de 2026

Decisión sobre el segundo intercalar y ciclo de avisos

• Un segundo intercalar puede introducirse en UTC según los cambios de UT1-TAI
• Los momentos posibles de introducción son finales de junio o finales de diciembre de cada año
• El Bulletin C se emite cada 6 meses
  • Si hay un paso temporal en UTC, se anuncia
  • Si no hay paso temporal en la siguiente fecha posible, se confirma

[GN⁺]

Opiniones de Hacker News

• Me da curiosidad qué causa esta imprevisibilidad. Pensé que conocíamos la rotación y la órbita de la Tierra hasta varios decimales, ¿pero será que factores como la actividad geológica o el clima generan diferencias en la velocidad de rotación y por eso es difícil predecirla?

  • En pocas palabras, sí. El clima, la actividad geológica, y también el traslado de agua por parte de los humanos, como el agotamiento de acuíferos y la construcción de represas, además del derretimiento de glaciares y hielo, introducen cambios difíciles de predecir en el período de rotación de la Tierra y en su eje de rotación.
    Según recuerdo, estos modelos son polinomios trigonométricos de bajo orden, así que incluso si modelaran perfectamente la imprevisibilidad, por el error de truncamiento sería difícil distribuirlos con una precisión muy alta; además, ya están incorporados en lugares como satélites, así que tampoco se pueden volver arbitrariamente complejos.
    Como referencia, los segundos intercalares pronto van a desaparecer, y entiendo que se eliminarán gradualmente en 2035. Recuerdo que se retrasó porque Rusia necesitaba tiempo para actualizar los satélites GLONASS.
  • Correcto. Están esos factores y muchos más. Nuestra precisión de medición es mucho mejor que las tasas de cambio de primer y segundo orden, que varían de un año a otro, en la duración del día.
    https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... es el gráfico más relacionado con esto, y los saltos verticales representan segundos intercalares. En el IERS también hay gráficos sobre otras dimensiones de la rotación, pero este se ve bien.
  • Justo revisé el artículo de Wikipedia para ver cuándo se agregó el último segundo intercalar, y la respuesta también está ahí:
    “La velocidad de rotación de la Tierra cambia en respuesta a eventos climáticos y geológicos, por lo que los segundos intercalares de UTC se colocan de forma irregular y no se pueden predecir con exactitud”.
    https://en.wikipedia.org/wiki/Leap_second
  • En realidad es casi lo contrario. La rotación de la Tierra puede variar incluso en el orden de varios segundos de un año a otro, pero a lo largo de cientos de años las variaciones tienden en gran medida a compensarse.
    Por eso creo que intentar agregar o quitar segundos intercalares no es una muy buena idea. En la práctica, quienes se preocupan por estas cosas son básicamente las agencias espaciales; ellas pueden aplicar las correcciones que quieran, sin necesidad de afectar a todo el mundo.
    El impacto real de este drift para la gente común sería algo como el GPS, pero el GPS ya transmite el desfase respecto de su propio reloj para que el receptor pueda corregirlo. El reloj del GPS no es igual ni a UTC ni a TAI.
  • Puedes ver https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co....

• ¿Esto no es más bien una antnoticia? Recuerdo vagamente que, como causa demasiados problemas en los sistemas informáticos actuales, se detuvo la introducción de segundos intercalares hasta nuevo aviso.
  Ahora la diferencia es de 37 segundos, y nadie tiene que preocuparse de que Navidad se desplace hacia la época de Pascua. Creo que este problema puede pasarse a las generaciones futuras de manera mucho más responsable que muchos otros.
  Que salga un aviso cada 6 meses es solo un procedimiento para cumplir con la redacción del tratado internacional original.

  • Todavía no es así. Es solo una propuesta, y probablemente sea difícil que la suspensión oficial ocurra antes de 2035.
    La razón por la que no ha habido segundos intercalares durante un tiempo es que el drift entre TAI y UT1 se volvió más lento y, de hecho, se está moviendo muy lentamente en la dirección opuesta.
  • Que el período de aviso sea de solo 6 meses me parece absurdo, y probablemente sea la causa del problema.
    Aunque la hora estuviera errada por unos ±60 segundos, nadie lo notaría, así que parecería más manejable insertar un segundo intercalar arbitrario cada 10 años y avisarlo con 10 años de anticipación, para que todos tengan tiempo de ordenar sus sistemas. Seis meses para coordinarlo y ejecutarlo en todo el mundo es ridículamente optimista.

• Explicándolo como si tuviera 5 años, me da curiosidad qué efecto tiene esto en los timestamps de UNIX, especialmente en cosas que están en modo mantenimiento o casi no se administran.
  En mi trabajo no necesito este nivel de precisión, pero seguramente hay áreas que sí lo necesitan.

  • Los timestamps de UNIX ignoran por completo los segundos intercalares y los tratan como si no existieran.
    Por eso, cuando se inserta un segundo intercalar, puede aparecer un segundo físico que no se puede referenciar con un timestamp de UNIX, y cuando se elimina un segundo intercalar, puede aparecer un timestamp de UNIX para un segundo que en realidad no existe.
  • Cada vez que se agregaba un segundo intercalar, Google hacía que los relojes de sus servidores avanzaran más lento o más rápido durante un período más largo, por lo general varias horas, para volver a sincronizarlos gradualmente con algún reloj de péndulo perfectamente esférico de platino puro que está en algún lugar del NIST: https://developers.google.com/time/smear
  • Los resultados de time() y clock_gettime(CLOCK_REALTIME) se ven afectados por los segundos intercalares.
    Un nuevo segundo intercalar llega al sistema a través de NTP. Lamentablemente, NTP solo distribuye una bandera que indica que se introducirá un segundo intercalar, no distribuye el offset en sí. Pero como la hora distribuida ya está afectada por el segundo intercalar, el cliente NTP no necesariamente necesita saberlo.
    En cambio, otros métodos de sincronización horaria como GPS y PTP usan escalas de tiempo que no se ven afectadas por los segundos intercalares y distribuyen el offset UTC como información adicional. Corregir la hora recibida al final queda a cargo del cliente. El kernel tiene un parámetro clock_adjtime() para segundos intercalares.
    Si es un sistema manual con cliente NTP, durante la ejecución la hora cambiará para ajustarse al nuevo segundo intercalar. Linux trata la hora UTC como prioridad, por lo que esto se guarda en el dispositivo RTC y se conserva después de reiniciar.
    CLOCK_TAI parecería tener que devolver la hora TAI, pero en distribuciones comunes de escritorio y servidor de Linux se lo trata como de segunda clase, al punto de que ni siquiera configuran el offset y devuelve la misma hora que CLOCK_REALTIME.
    En /etc hay un archivo con la lista de segundos intercalares incluido en algún paquete, así que para actualizar ese archivo se necesita una actualización del sistema. No creo que el software NTP tradicional actualice dinámicamente este paquete. De todos modos, tampoco hay mucho software que use este archivo.
    Si algún script de servicio de init lo parsea y configura el offset UTC del kernel, hasta que se actualice el sistema, CLOCK_TAI podría quedar 1 segundo atrasado respecto del resto del mundo. Pero, hasta donde sé, no tiene ningún efecto en la hora UTC de Linux.

• La frase “a las instituciones responsables de la medición y distribución del tiempo” es un preámbulo histórico

  • Lo mejor es que el nombre de esa organización es International Earth Rotation Service
  • Durante varios años, el cargo de liderazgo que supervisaba todo tipo de productos de tiempo de precisión en el USNO era “Director of the Directorate of Time”
  • Suena como algo que saldría en una novela de Douglas Adams
  • “Director Earth Orientation Center of IERS Observatoire de Paris, France”
    Hasta el cargo suena a ciencia ficción

• Si el offset UTC-TAI se mantiene en -37 segundos, significa que el offset UTC-GPS también se mantiene en -18 segundos
  TAI y GPS tienen un offset constante de 19 segundos entre ambos sistemas

• Me pregunto qué pasa en una situación así con sistemas como Spanner
  ¿Es un dolor de cabeza o no es gran cosa?

  • Es un problema grande. La forma más común de manejarlo se llama smearing y ajusta la duración de cada segundo durante las 24 horas previas al “segundo intercalar”
    En sistemas que requieren garantías estrictas de orden, funciona porque cada dispositivo se mantiene sincronizado con el reloj global y solo cambia muy ligeramente la duración del ciclo del reloj. De hecho, recuerdo que estaba en el paper original de Spanner
    Algunos sistemas raros usan segundos de osciladores monótonos e ignoran los segundos de la rotación terrestre, pero si algún día hay que convertir eso a tiempo real, el desastre se acumula con el tiempo y en general se considera una mala idea
  • Los segundos intercalares no se agregan con un calendario regular como los días bisiestos, sino que dependen de mediciones físicas de la Tierra
    Por eso, no creo que un sistema de alta confiabilidad con una gestión integral del tiempo se vea demasiado sacudido por este tipo de decisión

• Con la Temporal API, ¿los navegadores, Node.js y demás podrían manejar correctamente el tiempo en operaciones alrededor de ese momento? ¿O necesitarían una actualización para no arruinar los cálculos?

  • La Temporal API parece basarse en timestamps Unix/POSIX, que ignoran los segundos intercalares. En el tiempo Unix, un día siempre tiene 86400 “segundos”
    Por eso, sin una base de datos, es fácil hacer cálculos de calendario UTC pasados y futuros, y tampoco hace falta manejar necesariamente fracciones de segundo. Los segundos intercalares los maneja el sistema operativo repitiendo o saltándose un segundo, o ajustando la duración de los segundos durante cierto periodo antes y después del segundo intercalar
    La mayoría de las API de fecha y hora están diseñadas básicamente para soportar operaciones de calendario y reloj de pared para funciones de negocio. Si necesitas segundos SI para fines científicos, debes usar API y funciones separadas que proporcionen y garanticen la semántica necesaria hasta el nivel de hardware
    Del mismo modo, si necesitas timers para funciones de software como sleep de hilos, debes usar una interfaz dedicada como un reloj monótono. Aunque los segundos intercalares se eliminen gradualmente, esta situación no cambia mucho. Con o sin ajuste de segundos intercalares, por ejemplo, que un algoritmo de mutex dependa de timestamps Unix estaba mal antes y seguirá estando mal

• Escúchenme. Pongamos motores a reacción en el ecuador y hagámoslos girar 180 grados para ganar o perder tiempo. Y luego conectemos eso a mi botón de snooze

  • ¿No sería más fácil que Superman diera muchas vueltas alrededor de la Tierra a toda velocidad? Así no habría que preocuparse por el mantenimiento de los motores
  • En realidad, mover cantidades enormes de agua podría tener un efecto medible. Por ejemplo, agotar los acuíferos del Central Valley de California
  • El problema es que una sociedad futura recupere esos motores para usarlos en naves interestelares. Ese problema se trató en una serie de libros de Larry Niven
  • Capaz que basta con que todos saltemos al mismo tiempo. Total, solo se necesitan 1 o 2 segundos, ¿no?
  • Viendo que durante un tiempo no hizo falta meter segundos intercalares, parece que este método funcionó

• Dice: “La diferencia entre UTC y TAI es UTC-TAI = -37s desde las 0:00 UTC del 1 de enero de 2017 hasta nuevo aviso”
  ¿Eso significa que los relojes atómicos están 37 segundos atrasados respecto de los relojes solares? Tampoco entiendo por qué menciona 2017

  • Más bien es casi lo contrario
    Un día UTC se define como exactamente 86400 segundos SI. Pero el día solar medio real dura unos milisegundos más. Por las irregularidades de la rotación terrestre, la diferencia no es constante, pero se espera que la diferencia promedio crezca lentamente con el tiempo. Como los segundos SI se cuentan con relojes atómicos, UTC pasa al día siguiente cada 86400 segundos de reloj atómico
    En cambio, un reloj solar que pasa al día siguiente cada vez que el sol medio llega al mediodía lo hace unos milisegundos más tarde que UTC. Como la velocidad con la que el sol real cruza el cielo varía durante el año, hay que usar el sol medio
    Dicho de otra forma, cada periodo que un reloj solar llama exactamente 86400 segundos dura unos milisegundos más medido por un reloj atómico
    Esto se acumula día tras día y, cuando llega casi a 1 segundo, se inserta un segundo intercalar en UTC para que ese día tenga 86401 segundos en vez de 86400. UTC no consiste simplemente en contar el tiempo de los relojes atómicos; también debe sincronizarse con el sol, porque muchas actividades humanas están ligadas a la posición del sol en el cielo
    Los humanos definieron “sincronizado con el sol” como “dentro de 1 segundo del sol medio”. Es decir, queremos que el mediodía UTC esté dentro de 1 segundo del mediodía del sol medio en el meridiano de Greenwich
    Por lo tanto, esos 37 segundos significan cuánto se habría atrasado el mediodía del sol medio respecto del mediodía UTC si no se hubieran usado segundos intercalares. Cuando fuera mediodía UTC, al sol medio todavía le habrían faltado 37 segundos para cruzar el meridiano de Greenwich en el cielo
  • Según Wikipedia, diciembre de 2016 fue la última vez que se insertó un segundo intercalar: https://en.wikipedia.org/wiki/Leap_second
  • Seguramente se menciona 2017 porque fue la última vez que cambió el offset. Por eso los -37 segundos siguen vigentes desde entonces