Isenção de responsabilidade:

Acabei de ler a lista de sites do StackExchange por cerca de 20 minutos, tentando descobrir onde postar isso. Se você conhece algum site mais adequado, mova esta pergunta para lá. Estou postando isso aqui porque o tempo unix me fez pensar.

Então, como todos sabemos, há hora unix e há UTC. O tempo Unix continua correndo, contando segundos - um segundo por segundo -, enquanto o UTC tenta manter o tempo nos formatos legíveis por humanos que usamos alinhados com a fase da Terra em sua rotação. Para fazer isso, o UTC insere segundos saltados de tempos em tempos.

Como o tempo é relativo à força gravitacional ao qual o objeto experimenta o tempo é exposto, outros tipos de aceleração e velocidade relativa, isso leva a duas perguntas. Vamos superar o simples primeiro: onde é medido o tempo unix? Se Alice e Bob começarem a concordar que a hora atual é 1467932496.42732894722748 quando estão no mesmo local (um segundo curso é definido como 9'192'631'770 ciclos de radiação correspondentes à transição entre dois níveis de energia do césio-133 átomo em repouso e a 0 K), experimenta um paradoxo duplo, porque Alice vive no nível do mar e Bob vive no alto das montanhas ou Alice vive no pólo norte e Bob vive no equador, eles não concordam mais. Então, como o tempo unix é definido com precisão?

Você pode não perceber o problema com o UTC no início, porque certamente todos podem concordar quando a Terra completou uma órbita (isso obviamente ignora o movimento das placas continentais, mas acho que descobrimos isso muito bem porque, com o GPS, é possível medir seu movimento com muita precisão e podemos supor que eles estejam em uma posição definida em nosso modelo e não se movam à medida que as placas continentais mudam), independentemente de estarem em uma montanha, no nível do mar, no equador ou no pólo norte. Pode haver algumas diferenças de tempo, mas elas não se acumulam.

Mas um segundo é definido como 9'192'631'770 ciclos de radiação correspondentes à transição entre dois níveis de energia do átomo de césio-133 em repouso e a 0 K e o átomo de césio-133 não se importam com a órbita da Terra. Assim, o UTC decide onde inserir um salto de segundo, mas deve haver uma mudança medida ou prevista entre a fase da órbita da Terra e o tempo medido em algum lugar por um relógio atômico. Onde fica isso em algum lugar?

Sua pergunta principal não tem uma resposta real; O tempo Unix não é uma escala de tempo real e não é "medido" em lugar nenhum. É uma representação do UTC, embora ruim, porque há momentos no UTC que não podem representar. A hora do Unix insiste em que haja 86.400 segundos todos os dias, mas o UTC se desvia disso devido a segundos bissextos.

Quanto à sua pergunta mais ampla, há quatro importantes escalas de tempo de interesse:

1. UT1 (Tempo Universal), calculado por observatórios de todo o mundo que medem a rotação da Terra em relação às estrelas fixas. Com essas observações e um pouco de matemática, obtemos uma versão mais moderna do antigo horário médio de Greenwich, que foi baseado no momento do meio-dia solar no Observatório Real de Greenwich. O Tempo Universal é calculado por Uma organização chamada IERS (Serviço Internacional de Sistemas de Referência e Rotação da Terra, anteriormente conhecido como Serviço Internacional de Rotação da Terra).

2. O TAI (International Atomic Time), que é mantido por centenas de relógios atômicos em todo o mundo, mantido por órgãos de normas nacionais e outros. Os detentores dos relógios que contribuem para a TAI usam técnicas de transferência de tempo para direcionar seus relógios um para o outro, cancelando pequenos erros de relógios individuais e criando um tempo de conjunto; esse conjunto é o TAI, publicado pelo Bureau Internacional de Pesos e Medidas (BIPM), os administradores do sistema de unidades SI. Para responder à sua pergunta sobre dilatação do tempo, TAI é definido como tempo atômico ao nível do mar (na verdade, no geóide, que é uma versão mais sofisticada da mesma idéia), e cada relógio corrige os efeitos de sua própria altitude.

3. UTC (Horário Universal Coordenado). O UTC foi definido igual a dez segundos atrás do TAI em 1 de janeiro de 1972 e, desde essa data, ele avança exatamente na mesma taxa que o TAI, exceto quando um salto de segundo é adicionado ou subtraído. O IERS toma a decisão de anunciar um segundo de salto para manter a diferença em 0,9 segundos (na prática, em cerca de 0,6 segundos; um segundo de salto adicional faz com que a diferença passe de -0,6 para +0,4). Em teoria, os segundos bissextos podem ser positivos e negativos, mas como a rotação da Terra está diminuindo em comparação com o padrão estabelecido por SI e TAI, um segundo negativo nunca foi necessário e provavelmente nunca será.

4. Hora Unix, que faz o possível para representar o UTC como um único número. Cada hora do Unix que é múltiplo de 86.400 corresponde à meia-noite UTC. Como nem todos os dias UTC têm 86.400 segundos de duração, mas todos os "dias Unix", existe uma diferença irreconciliável que precisa ser corrigida de alguma forma. Não há tempo Unix correspondente a um segundo de salto adicional. Na prática, os sistemas agem como se o segundo anterior tivesse ocorrido duas vezes (com o timestamp do unix pulando um segundo para trás e depois avançando novamente), ou aplicando uma técnica como a mancha de salto que distorce o tempo por um longo período de tempo em ambos os lados do um salto de segundo. Em ambos os casos, há alguma imprecisão, embora pelo menos a segunda seja monotônica. Em ambos os casos,e b não é igual a ba; é igual a ba mais o número de segundos intercalados do salto .

Como UT1, TAI, UTC e IERS são todos esforços multinacionais em todo o mundo, não existe um único "onde", embora os boletins IERS sejam publicados no Observatório de Paris e o BIPM também esteja sediado em Paris, essa é uma resposta. Uma organização que requer tempo preciso e rastreável pode declarar sua base de tempo como algo como "UTC (USNO)", o que significa que seus carimbos de data e hora estão no UTC e que são derivados do horário no Observatório Naval dos EUA, mas considerando os problemas que Eu mencionei com o tempo Unix, é basicamente incompatível com esse nível de precisão - qualquer pessoa que lide com um tempo realmente preciso terá uma alternativa ao tempo Unix.

Os ajustes no relógio são coordenados pelo IERS. Eles agendam a inserção de um salto de segundo no fluxo de tempo, conforme necessário.

Da escala de tempo NTP e segundos bissextos

O Serviço Internacional de Rotação da Terra (IERS) no Observatório de Paris usa observações astronômicas fornecidas pelo USNO e outros observatórios para determinar a escala de tempo do UT1 (navegador) corrigida por variações irregulares na rotação da Terra.

De acordo com o meu conhecimento, 23:59:60 (Leap Second) e 00:00:00 no dia seguinte são considerados o mesmo segundo no Unix Time.

O tempo UNIX é medido no seu computador, executando o UNIX.

Esta resposta espera que você saiba o que são o Tempo Universal Co-ordenado (UTC), o Tempo Atômico Internacional (TAI) e o segundo SI. Explicá-los está muito além do escopo do Unix e Linux Stack Exchange. Esta não é a troca de pilhas de física ou astronomia.

O hardware

Seu computador contém vários osciladores que acionam relógios e cronômetros. Exatamente o que tem varia de computador para computador, dependendo de sua arquitetura. Mas geralmente, e em termos muito gerais:

• Existe um temporizador de intervalo programável (PIT) em algum lugar, que pode ser programado para contar um determinado número de oscilações e acionar uma interrupção na unidade central de processamento.
• Existe um contador de ciclos no processador central que simplesmente conta 1 para cada ciclo de instruções executado.

A teoria da operação, em termos muito amplos

O kernel do sistema operacional utiliza o PIT para gerar ticks . Ele configura o PIT para execução livre, contando o número certo de oscilações por um intervalo de tempo de, digamos, um centésimo de segundo, gerando uma interrupção e redefinindo automaticamente a contagem para continuar novamente. Existem variações nisso, mas, em essência, isso faz com que uma interrupção de escala seja aumentada com uma frequência fixa.

No software, o kernel incrementa um contador a cada tick. Ele conhece a frequência do tick, porque programou o PIT em primeiro lugar. Portanto, ele sabe quantos ticks compõem um segundo. Pode ser usado para saber quando incrementar um contador que conta segundos. Este último é a idéia do kernel de "UNIX Time". De fato, ele simplesmente conta para cima na taxa de um por segundo de SI, se for deixado para seus próprios dispositivos.

Quatro coisas complicam isso, que vou apresentar em termos muito gerais.

O hardware não é perfeito. Um PIT cuja folha de dados diz que possui uma frequência de oscilador de N Hertz pode ter uma frequência de (digamos) N .00002 Hertz, com as conseqüências óbvias.

Esse esquema interage muito mal com o gerenciamento de energia, porque a CPU está acordando centenas de vezes por segundo para fazer pouco mais do que incrementar um número em uma variável. Portanto, alguns sistemas operacionais têm o que chamamos de design "sem marcação". Em vez de fazer com que o PIT envie uma interrupção para cada tick, o kernel calcula (a partir do agendador de baixo nível) quantos ticks vão passar sem quanta de threads esgotando e programa o PIT para contar para esse ticks no futuro antes de emitir uma interrupção de escala. Ele sabe que precisa registrar a passagem de N ticks na próxima interrupção, em vez de 1 tick.

O software de aplicativo tem a capacidade de alterar o horário atual do kernel. Ele pode aumentar o valor ou reduzir o valor. O giro envolve o ajuste do número de ticks que precisam passar para aumentar o contador de segundos. Assim, os segundos contador não necessariamente contar à taxa de um por segundo SI qualquer maneira , mesmo assumindo osciladores perfeitos. O passo envolve simplesmente escrever um novo número no contador de segundos, o que geralmente não acontece até 1 segundo de SI desde o último segundo.

Os kernels modernos não apenas contam segundos, mas também nanossegundos. Mas é ridículo e muitas vezes completamente inviável ter uma interrupção de uma vez por nanossegundo. É aqui que coisas como o contador de ciclos entram em cena. O kernel lembra o valor do contador de ciclos a cada segundo (ou a cada tick) e pode calcular, a partir do valor atual do contador, quando algo quer saber o tempo em nanossegundos, quantos nanossegundos devem ter decorrido desde o último segundo (ou Carraça). Mais uma vez, porém, o gerenciamento de energia e térmica causa estragos nisso, pois a frequência do ciclo de instruções pode mudar, de modo que os kernels fazem coisas como confiar em hardware adicional, como (digamos) um HPET (Temporizador de Eventos de Alta Precisão).

A linguagem C e POSIX

A biblioteca padrão da linguagem C descreve o tempo em termos de um tipo, opaco time_t, um tipo de estrutura tmcom vários campos especificados, e várias funções da biblioteca como time(), mktime()e localtime().

Em resumo: a própria linguagem C apenas garante que esse time_té um dos tipos de dados numéricos disponíveis e que a única maneira confiável de calcular diferenças de tempo é a difftime()função. É o padrão POSIX que fornece garantias mais rigorosas, que time_té de fato um dos tipos inteiros e conta em segundos desde a época . É também o padrão POSIX que especifica o timespectipo de estrutura.

A time()função é por vezes descrito como uma chamada de sistema. De fato, não é a chamada subjacente ao sistema em muitos sistemas há bastante tempo, atualmente. No FreeBSD, por exemplo, a chamada do sistema subjacente é clock_gettime(), que possui vários "relógios" disponíveis que medem em segundos ou segundos + nanossegundos de várias maneiras. É essa chamada de sistema pela qual o software de aplicativos lê o UNIX Time no kernel. (Uma clock_settime()chamada do sistema correspondente permite que eles o sigam e uma adjtime()chamada do sistema permite que eles o matem.)

Muitas pessoas acenam com o padrão POSIX com afirmações muito definidas e exatas sobre o que ele prescreve. Essas pessoas, na maioria das vezes, na verdade não leem o padrão POSIX. Como sua lógica expõe, a idéia de contar "segundos desde a época", que é a frase que o padrão usa, intencionalmente não especifica que os segundos POSIX têm a mesma duração que os segundos SI, nem que o resultado de gmtime()"é necessariamente" UTC, apesar de sua aparência ". O padrão POSIX é intencionalmentesolte o suficiente para permitir (digamos) um sistema UNIX para o qual o administrador vá e conserte manualmente os ajustes de segundos após o reajuste do relógio na semana seguinte. De fato, o raciocínio indica que ele é intencionalmente frouxo o suficiente para acomodar sistemas em que o relógio foi deliberadamente acertado em algum momento diferente do horário atual do UTC.

UTC e TAI

A interpretação do UNIX Time obtida do kernel depende das rotinas da biblioteca em execução nos aplicativos. POSIX especifica uma identidade entre o tempo do kernel e um "tempo de quebra" em um arquivo struct tm. Mas, como Daniel J. Bernstein apontou certa vez, a edição de 1997 da norma errou embaraçosamente essa identidade, atrapalhando a regra do ano bissexto do calendário gregoriano (algo que as crianças em idade escolar aprendem) para que o cálculo estivesse errado a partir do ano 2100 em diante. "Mais honrado na violação do que na observância" é uma frase que vem prontamente à mente.

E de fato é. Atualmente, vários sistemas baseiam essa interpretação em rotinas de bibliotecas escritas por Arthur David Olson, que consultam o infame "banco de dados de fuso horário Olson", geralmente codificado nos arquivos de banco de dados abaixo /usr/share/zoneinfo/. O sistema Olson tinha dois modos:

• Os "segundos desde a época" do kernel são considerados como segundos UTC desde 1970-01-01 00:00:00 UTC, exceto por segundos bissextos. Isso usa o posix/conjunto de arquivos de banco de dados do fuso horário da Olson. Todos os dias têm 86400 segundos de kernel e nunca há 61 segundos em um minuto, mas eles nem sempre têm a duração de um segundo de SI e o relógio do kernel precisa ser girado ou pisado quando ocorrem segundos bissextos.
• Considera-se que os "segundos desde a época" do kernel contam segundos TAI desde TAI 1970-01-01 00:00:10. Isso usa o right/conjunto de arquivos de banco de dados do fuso horário da Olson. Os segundos do kernel têm 1 SI segundo de duração e o relógio do kernel nunca precisa ser girado ou pisado para ajustar os segundos bissextos, mas os tempos de quebra podem ter valores como 23:59:60 e os dias nem sempre são 86400 segundos do kernel.

M. Bernstein escreveu várias ferramentas, incluindo o seu daemontoolsconjunto de ferramentas, que right/eram necessárias porque simplesmente adicionavam 10 time_tpara obter segundos TAI desde 1970-01-01 00:00:00 TAI. Ele documentou isso na página de manual.

Esse requisito foi (talvez sem o saber) herdado por conjuntos de ferramentas como daemontools-encoree runite por Felix von Leitner libowfat. Use Bernsteinmultilog , Guentermultilog ou Papesvlogd com uma posix/configuração Olson , por exemplo, e todos os carimbos de data e hora TAI64N estarão (no momento em que foram escritos) 26 segundos atrás da contagem real de segundos TAI desde 1970-01-01 00:00:10 TAI.

Laurent Bercot e eu abordamos isso em s6 e nosh, embora tenhamos adotado abordagens diferentes. M. Bercot tai_from_sysclock()depende de um sinalizador em tempo de compilação. as ferramentas de nosh que tratam do TAI64N examinam as variáveis ​​de ambiente TZe TZDIRpara detectar automaticamente posix/e right/se puderem.

Curiosamente, documentos time2posix()e posix2time()funções do FreeBSD que permitem o equivalente ao right/modo Olson com time_tsegundos TAI. Aparentemente, eles não estão ativados.

De novo…

O tempo UNIX é medido no seu computador executando o UNIX, por osciladores contidos no hardware do seu computador. Ele não usa segundos SI; não é UTC, embora possa parecer superficialmente; e intencionalmente permite que seu relógio esteja errado.

Leitura adicional

• Daniel J. Bernstein. Hora UTC, TAI e UNIX . cr.yp.to.
• Daniel J. Bernstein. tai64nlocal. Daemon Tools. cr.yp.to.
• " segundos desde a época ". Única Especificação UNIX Versão 2 . 1997. The Open Group.
• " Segundos desde a época (justificativa) ". Especificações básicas Edição 6 . 2004. IEEE 1003.1. O grupo aberto.
• David Madore (17/12/2010). O Unix salta a segunda bagunça .
• time2posix. Manual do FreeBSD 10.3. § 3
• /physics/45739/
• /astronomy/11840/