Nenhum segundo intercalar será adicionado no fim de dezembro de 2026

 (datacenter.iers.org)
1 pontos por GN⁺ 5 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • De acordo com o IERS Bulletin C 72, nenhum segundo intercalar será adicionado ao UTC no fim de dezembro de 2026, portanto sistemas de medição e distribuição de tempo não precisam preparar nenhum tratamento especial de inserção
  • A diferença entre UTC e TAI permanecerá como UTC-TAI = -37 s a partir de 1º de janeiro de 2017, 0h UTC, até novo aviso
  • A introdução de segundos intercalares é decidida conforme a variação de UT1-TAI, e os momentos possíveis são o fim de junho ou o fim de dezembro
  • O Bulletin C anuncia uma etapa de tempo (time step) do UTC a cada seis meses ou confirma que não haverá etapa de tempo na próxima data possível
  • Para a distribuição do UTC no fim de 2026, não será necessário um novo valor de correção; basta continuar usando a relação existente UTC-TAI = -37 s

Comunicado sobre UTC no IERS Bulletin C 72

  • O Bulletin C 72, emitido pelo IERS em 6 de julho de 2026 em Paris, informa que não será introduzido segundo intercalar no fim de dezembro de 2026
  • O comunicado é destinado a instituições responsáveis pela medição e distribuição de tempo
  • Os dois valores principais são os seguintes
    • A partir de 1º de janeiro de 2017, 0h UTC, até novo aviso, UTC-TAI = -37 s
    • No fim de dezembro de 2026, não haverá nova etapa de tempo no UTC

Decisão sobre segundos intercalares e periodicidade dos comunicados

  • Segundos intercalares podem ser introduzidos no UTC conforme a variação de UT1-TAI
  • Os momentos possíveis de introdução são o fim de junho ou o fim de dezembro de cada ano
  • O Bulletin C é enviado a cada seis meses
    • Se houver uma etapa de tempo no UTC, ela é anunciada
    • Se não houver etapa de tempo na próxima data possível, isso é confirmado

Leituras relacionadas

1 comentários

 
GN⁺ 5 시간 전
Comentários do Hacker News

  • Fico me perguntando de onde vem essa imprevisibilidade. Eu imaginava que já soubéssemos a rotação e a translação da Terra com várias casas decimais; será que fatores como atividade geológica ou clima criam diferenças na velocidade de rotação e por isso fica difícil prever?

    • Em resumo, sim. Clima, atividade geológica e também o movimento de água causado por humanos, como esgotamento de aquíferos e construção de represas, além do derretimento de geleiras e do gelo, tudo isso introduz mudanças difíceis de prever no período de rotação e no eixo da Terra
      Pelo que lembro, esses modelos são polinômios trigonométricos de baixa ordem, então mesmo que modelassem perfeitamente a imprevisibilidade, seria difícil distribuí-los com precisão muito alta por causa do erro de truncamento; além disso, eles já estão embarcados em coisas como satélites, então também não dá para torná-los arbitrariamente complexos
      Aliás, segundos intercalares devem desaparecer em breve, e pelo que sei serão descontinuados gradualmente em 2035. Lembro que houve atraso porque a Russia precisava de tempo para atualizar os satélites GLONASS
    • Sim. Existem esses fatores e vários outros. Nossa precisão de medição é muito melhor do que as variações anuais de primeira e segunda derivada da duração do dia
      https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... é o gráfico mais relevante sobre isso, e os saltos verticais representam segundos intercalares. O IERS também tem gráficos de outras dimensões da rotação, mas este é fácil de visualizar
    • Fui checar o artigo da Wikipedia justamente para ver quando foi o último segundo intercalar, e a resposta também está lá
      “A velocidade de rotação da Terra varia em resposta a eventos climáticos e geológicos; por isso, os segundos intercalares do UTC são colocados de forma irregular e não podem ser previstos com exatidão”
      https://en.wikipedia.org/wiki/Leap_second
    • Na verdade, é quase o contrário. A rotação da Terra pode variar em vários segundos ao longo de um ano, mas ao longo de séculos essas flutuações tendem a se compensar
      Por isso, não acho que tentar adicionar ou remover segundos intercalares seja uma boa ideia. Na prática, quem se importa com isso são só as agências espaciais, e elas podem aplicar a correção que quiserem sem precisar afetar todo mundo
      O único impacto prático desse drift para o público em geral é algo como GPS, mas o GPS já transmite o deslocamento em relação ao seu próprio relógio para que o receptor possa corrigir. O relógio do GPS não é igual nem ao UTC nem ao TAI
    • É só ver https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co...

  • Isso não seria uma antinotícia? Tenho uma vaga lembrança de que pararam de introduzir segundos intercalares porque eles causavam problemas demais nos sistemas de computação atuais, até novo aviso
    Agora a diferença está em 37 segundos, e ninguém precisa se preocupar que o Natal vá escorregar para perto da Páscoa. Acho que esse é um problema que dá para passar de forma bem responsável para as próximas gerações, mais do que muitos outros
    Esse anúncio semestral é só um procedimento para cumprir a redação do tratado internacional original

    • Ainda não chegou a esse ponto. É só uma proposta, e a suspensão oficial provavelmente não acontece antes de 2035
      A razão de não ter havido segundos intercalares por um tempo é que o drift entre TAI e UT1 desacelerou e, na verdade, está indo muito lentamente na direção oposta
    • Parece absurdo que o período de aviso seja de apenas 6 meses, e isso provavelmente é a origem do problema
      Ninguém perceberia se a hora ficasse errada em algo como ±60 segundos, então parece mais administrável inserir um segundo intercalar arbitrário uma vez a cada 10 anos e avisar com 10 anos de antecedência, para que todo mundo tenha tempo de arrumar os sistemas. Seis meses é um otimismo absurdo para algo que precisa ser coordenado e executado globalmente

  • Explicando como se eu tivesse 5 anos, queria entender o efeito disso nos timestamps UNIX. Especialmente em coisas que estão em modo de manutenção ou quase sem administração
    No meu trabalho eu não preciso desse nível de precisão, mas certamente existem áreas que precisam

    • Timestamps UNIX ignoram completamente os segundos intercalares e tratam como se eles não existissem
      Então, quando um segundo intercalar é inserido, pode existir um segundo físico que não pode ser referenciado por um timestamp UNIX; e quando um segundo intercalar é removido, pode existir um timestamp UNIX para um segundo que na prática nunca existiu
    • Sempre que um segundo intercalar era adicionado, o Google fazia os relógios dos servidores rodarem um pouco mais devagar ou mais rápido ao longo de um período maior, geralmente algumas horas, para se realinhar lentamente com algum relógio de pêndulo perfeitamente esférico de platina pura do NIST em algum lugar: https://developers.google.com/time/smear
    • Os resultados de time() e clock_gettime(CLOCK_REALTIME) são afetados por segundos intercalares
      Um novo segundo intercalar chega ao sistema via NTP. Infelizmente, o NTP só distribui uma flag indicando que um segundo intercalar será introduzido, e não o próprio deslocamento. Mas o horário distribuído em si já é afetado pelo segundo intercalar, então o cliente NTP não precisa necessariamente saber disso
      Em contraste, outros métodos de sincronização, como GPS e PTP, usam escalas de tempo não afetadas por segundos intercalares e distribuem o deslocamento em relação ao UTC como informação adicional. Ajustar o horário recebido no final fica por conta do cliente. O kernel tem um parâmetro clock_adjtime() para segundos intercalares
      Em um sistema manual com cliente NTP, o horário muda durante a execução para se ajustar ao novo segundo intercalar. O Linux trata o horário UTC como prioritário, então isso é armazenado no dispositivo RTC e persiste após reinicialização
      CLOCK_TAI parece que deveria retornar tempo TAI, mas nas distribuições comuns de desktop e servidor Linux ele é tratado como cidadão de segunda classe a ponto de nem configurarem o deslocamento, então acaba retornando o mesmo horário que CLOCK_REALTIME
      Em /etc existe um arquivo com a lista de segundos intercalares incluído por algum pacote, e para atualizar esse arquivo é preciso atualizar o sistema. Não acredito que o software NTP tradicional atualize esse pacote dinamicamente. De qualquer forma, também não há muito software que use esse arquivo
      Se algum script de serviço init fizer o parse disso para configurar o deslocamento UTC do kernel, então até a atualização o CLOCK_TAI do sistema pode ficar 1 segundo atrás do resto do mundo. Mas, até onde eu sei, isso não afeta em nada o horário UTC no Linux

  • A frase “às instituições responsáveis pela medição e distribuição do tempo” é uma pérola histórica

    • Melhor ainda é o nome da organização: International Earth Rotation Service
    • Durante vários anos, o cargo de liderança no USNO que supervisionava vários produtos de tempo de alta precisão era “Director of the Directorate of Time”
    • Parece algo que sairia de um romance de Douglas Adams
    • “Director Earth Orientation Center of IERS Observatoire de Paris, France”
      Até o cargo parece ficção científica

  • Se o offset UTC-TAI continuar em -37 segundos, isso significa que o offset UTC-GPS também continua em -18 segundos
    TAI e GPS têm um offset fixo de 19 segundos entre si

  • Fico curioso sobre o que acontece com sistemas como o Spanner numa situação dessas
    É uma dor de cabeça ou não é nada demais?

    • É um problemão. A forma mais comum de lidar com isso é chamada de smearing, ajustando a duração de cada segundo ao longo das 24 horas anteriores ao “segundo intercalar”
      Em sistemas que exigem garantias estritas de ordenação, isso funciona porque cada dispositivo mantém a sincronização com um relógio global, e só a duração do ciclo do relógio varia muito ligeiramente. Se bem me lembro, isso estava no artigo original do Spanner
      Alguns sistemas mais raros usam segundos de oscilador monotônico e ignoram os segundos intercalares, mas se em algum momento você precisar converter isso para tempo real, o desastre vai se acumulando com o passar do tempo, e em geral isso não é considerado uma boa ideia
    • Segundos intercalares não são adicionados em um cronograma regular como anos bissextos, e sim variam conforme medições físicas da Terra
      Então sistemas de alta confiabilidade com gerenciamento de tempo abrangente provavelmente não vão ser muito abalados por esse tipo de decisão

  • Com a Temporal API, navegadores ou o Node.js conseguiriam tratar corretamente o tempo em operações perto desse momento, ou seria preciso atualização para não quebrar os cálculos?

    • A Temporal API parece se basear em timestamps Unix/POSIX, que ignoram segundos intercalares. No tempo Unix, um dia sempre tem 86400 “segundos”
      Isso facilita fazer cálculos de calendário UTC passados e futuros sem banco de dados, e também não exige necessariamente lidar com segundos fracionários. Segundos intercalares são tratados pelo sistema operacional repetindo ou pulando 1 segundo, ou ajustando a duração dos segundos durante um período antes e depois do segundo intercalar
      A maioria das APIs de data e hora é projetada principalmente para dar suporte a operações de calendário e relógio de parede para funcionalidades de negócio. Se você precisa de segundos SI para fins científicos, deve usar APIs e recursos separados que forneçam e garantam esse significado até o nível do hardware
      Da mesma forma, se você precisa de temporizadores para recursos de software como sleep de thread, deve usar interfaces dedicadas como relógios monotônicos. Mesmo que os segundos intercalares desapareçam aos poucos, essa situação não muda muito. Com ou sem ajuste de segundo intercalar, por exemplo, um algoritmo de mutex depender de timestamps Unix sempre foi errado e continuará sendo

  • Escuta só: a gente acopla um motor a jato no equador e gira 180 graus para ganhar ou perder tempo. Depois liga isso no meu botão de snooze

    • Não seria mais fácil o Superman dar várias voltas super-rápidas em torno da Terra? Aí não precisa se preocupar com manutenção do motor
    • Na prática, mover uma quantidade enorme de água talvez pudesse ter um efeito mensurável. Por exemplo, esgotando o aquífero do Central Valley da Califórnia
    • O problema é uma sociedade futura recolher esses motores para naves interestelares. Esse problema foi tratado numa série de livros do Larry Niven
    • Talvez fosse só todo mundo pular ao mesmo tempo. No fim, a gente só precisa de 1 ou 2 segundos, não?
    • Pelo fato de não ter sido necessário inserir segundos intercalares por um tempo, parece que esse método funcionou

  • Está escrito: “A diferença entre UTC e TAI é UTC-TAI = -37s a partir de 1º de janeiro de 2017, 0h UTC, até novo aviso”
    Isso quer dizer que o relógio atômico está 37 segundos atrasado em relação ao relógio solar? Também não entendi por que mencionam 2017

    • Na verdade é quase o contrário
      O dia em UTC é definido como tendo exatamente 86400 segundos SI. Mas o dia solar médio real é alguns milissegundos mais longo. Por causa das irregularidades na rotação da Terra, a diferença não é constante, mas espera-se que a diferença média aumente lentamente com o tempo. Como o segundo SI é contado por relógios atômicos, o UTC vira para o dia seguinte a cada 86400 segundos atômicos
      Já um relógio solar, que vira o dia sempre que o Sol médio chega ao meio-dia, vira alguns milissegundos depois do UTC. O Sol real cruza o céu em velocidades diferentes ao longo do ano, então é preciso usar o Sol médio
      Dito de outra forma, cada período que um relógio solar chama de exatamente 86400 segundos é, pelo relógio atômico, alguns milissegundos mais longo
      Isso vai se acumulando dia após dia, e quando chega perto de 1 segundo, um segundo intercalar é inserido no UTC, fazendo aquele dia ter 86401 segundos em vez de 86400. O UTC não existe apenas para contar o tempo atômico; ele também precisa continuar sincronizado com o Sol, porque muitas atividades humanas estão ligadas à posição do Sol no céu
      Os humanos definiram “sincronizado com o Sol” como “dentro de 1 segundo do Sol médio”. Ou seja, queremos que o meio-dia UTC fique a até 1 segundo do meio-dia solar médio no meridiano principal
      Portanto, esses 37 segundos significam o quanto o meio-dia solar médio teria ficado atrasado em relação ao meio-dia UTC se não fossem usados segundos intercalares. Quando fosse meio-dia UTC, ainda faltariam 37 segundos para o Sol médio cruzar o meridiano principal no céu
    • Segundo a Wikipedia, dezembro de 2016 foi a última vez em que um segundo intercalar foi inserido: https://en.wikipedia.org/wiki/Leap_second
    • A menção a 2017 provavelmente é porque foi quando o offset mudou pela última vez. Então esses -37 segundos continuam válidos desde então