Segundos do UNIX, segundos do TAI (SI), segundos do salto e o código do mundo real

Question

Eu li muito sobre o UNIX Time ultimamente, a maior parte dele incoerente, muito contraditório. Eu estou tentando reconciliar conversões entre o UNIX Time (a seguir, por simplicidade, UXT), TAI e UTC, e para fazer isso, eu preciso entender o UXT corretamente. O problema é que não consigo encontrar mais ninguém.

A seguir, a minha melhor tentativa de explicação, reconstruída a partir de inúmeras fontes por pesquisa tediosa. Também está errado em algum lugar. Estou à procura de uma análise holística e verificação / refutação ponto a ponto dos seguintes. Essencialmente, corrija o seguinte para que funcione.

1. O TAI é um padrão de tempo crescente monotonicamente. Ele marca SI segundos e ignora o horário de verão e pula segundos.

2. UTC é o mesmo que TAI, mas corrigido por um número inteiro de saltos SI segundos (conversões para sequências de tempo refletem isso como um 60º segundo) de modo a estar dentro de 0,9 SI segundos de UT1, um padrão astronômico de tempo .

3. O UXT é uma contagem de segundos do UNIX desde 1970-01-01 00:00:00 UTC. Há sempre exatamente 86400 segundos por dia. No entanto, o UXT está relacionado ao UTC.

4. Como isso é possível? Bem, o segundo UNIX precisa ser diferente do segundo SI , e porque Os segundos bissextos não são perfeitamente regulares, os segundos do UNIX não podem ter um período de tempo bem definido.

5. A conversão de UTC para UXT em §4.15 da especificação UNIX aliases diferentes tempos UTC para o mesmo registro de data e hora UXT, efetivamente fazendo com que os segundos do UNIX sejam iguais aos segundos SI (exceto para os segundos saltos do UNIX, que são dois segundos SI) .
   
   Na prática, o que realmente acontece varia. A maioria dos computadores é sincronizada com base em um servidor remoto e, portanto, eles lidam implicitamente com atualizações intercaladas durante a sincronização.

6. Tudo isso significa que, embora cada data / hora UXT individual possa ser convertida para / de UTC facilmente (use gmtime ou §4.15, respectivamente), você não pode fazer aritmética para descobrir qualquer coisa usando-os. Em particular, difftime retorna segundos do UNIX , e assim você não pode fazer nada com isso, incluindo adicioná-lo a um timestamp diferente, a menos que você saiba onde estão todos os segundos bissextos relevantes.

Acho que entendi até agora.

7. Mas agora analisamos o código real, que não faz nada disso. Eu posso entender pessoas medindo durações usando difftime e apenas esperando que seja bom o suficiente (ou não sabendo que há um problema), mas bibliotecas de cronometragem também estão erradas.
   
   Como um exemplo, libtai fornece uma conversão ( tai_now.c:7 ) para TAI de UXT como: TAI := 4,611,686,018,427,387,914 + UXT . Como o TAI monitora SI segundos, enquanto o UXT atinge segundos do UNIX, você simplesmente não pode fazer isso. No entanto, como libtai lida explicitamente com saltos de segundo, não parece razoável que isso seja um erro descuidado.
   
   Não é específico para libtai . Você vê todo esse tipo de coisa.

Então: os pontos 1-6 estão em desacordo com o ponto 7. Ou seja, toneladas de códigos existentes estão em contradição com os padrões de tempo que supostamente representam. O que deu errado?

    

Answer 1

Um problema é que a maioria dos documentos não usa um vocabulário que possa distinguir escalas de tempo sem sentenças de ambigüidade. Sugiro link como introdução ao problema de que, no uso histórico, há dois tipos de segundos não relacionados - um que é uma subdivisão de um dia de calendário para os residentes da Terra, e um que é uma duração constante medida em um referencial específico. Qualquer biblioteca de tempo que cubra datas antes e depois de 1970 está tentando fazer uso de ambos os tipos de segundo, e isso acaba fornecendo respostas que são semelhantes a uma função que afirma fornecer arcsin (-2) - o que significa dizer que há são complexidades envolvidas que precisam de explicações cuidadosas e definições de exatamente o que está sendo considerado importante.

    

Answer 2

Você está certo e essa bagunça é terrível. Minha conclusão:

UXT e UTC são os mesmos, exceto durante o segundo bissexto. Lá, o UTC conta até 60 e o UTX apenas "trava" por um segundo.