Ferramentas para desenvolvedores · Conversor de carimbo de data/hora Unix
Segundos bissextos e tempo Unix: por que a época finge que eles não existem
· Fundo
carimbos de data/hora horário unix fusos horários
UTC inseriu segundos bissextos desde 1972, mas o tempo Unix simplesmente não os conta, o que significa que alguns segundos aconteceram duas vezes. Este post explica por que, o que é difamação e por que toda a prática está programada para acabar.
O segundo que aconteceu duas vezes – um 23:59:60 em um sistema, um 23:59:59 repetido em outro e um erro de chave duplicada à meia-noite
ToolAcre não pode produzir uma linha ISO terminando em `23:59:60`. Seu teste nomeia o limite do segundo bissexto e espera que um valor de época seja formatado como `2016-12-31T23:59:59.000Z` e o próximo como `2017-01-01T00:00:00.000Z`. Não há nenhum segundo extra exibível entre eles.
Esse fato pode afetar logs cuja fonte externa utilizou outra convenção, mas este repositório não contém nenhuma evidência de incidente de chave duplicada. Se rótulos repetidos aparecerem em um sistema, inspecione o relógio e o caminho de armazenamento em vez de atribuí-los automaticamente ao conversor.
Um sistema que exige um rótulo exclusivo para cada segundo físico precisa, portanto, de mais contexto do que esse mapeamento Unix até o momento. O conversor não pode fabricar uma etiqueta que seu modelo omite.
ToolAcre prova que não há 23:59:60 representável; não documenta incidentes de chave duplicada
O esboço explicava o tempo atômico, a rotação da Terra e um limite de tolerância. Essas afirmações científicas e padronizadas não são estabelecidas pelo código de carimbo de data/hora ou testes. Eles são intencionalmente deixados de fora, em vez de parafraseados de memória. O mecanismo aqui não prova as razões por trás da política global de cronometragem.
Para usar esta rota, a evidência necessária é mais simples: a data e a saída ISO expõem os segundos rótulos comuns, e a época do estilo POSIX avança através do limite testado. Um tratamento de governança de segundo salto exigiria material confiável além dos caminhos de repositório permitidos.
Esta fronteira é explícita e não evasiva: os testes de software respondem a questões de representação, enquanto a história científica necessita de material escrito para esse fim e revisto nos seus próprios termos.
A justificativa física para segundos bissextos requer fontes fora deste repositório
O modelo implementado se comporta como se os dias civis em seu eixo tivessem 86,400 segundos Unix numerados. Entradas inteiras consecutivas diferem em um segundo, inclusive no limite de 2016 ano. `fromEpoch` multiplica cada um por 1,000 e Date formata a contagem de milissegundos resultante.
Chamar isso de “ignorar” segundos bissextos descreve a saída observável: nenhum valor Unix exclusivo é mapeado para um rótulo `:60`. Isso não implica que todos os relógios da máquina avancem de forma idêntica durante uma inserção real. O conversor aceita uma contagem; ele não amostra nem disciplina o relógio do host.
A aritmética em intervalos maiores segue a mesma convenção, portanto, subtrair dois valores Unix mede sua diferença de contagem no estilo POSIX em vez de reconstruir rótulos de salto omitidos.
A conversão testada não tem rótulo de segundo bissexto entre valores de época consecutivos
Os sistemas podem aplicar etapas, repetições ou esfregaços, mas o repositório não identifica quais provedores utilizam qual método, em que intervalo ou com qual fórmula. Publicar esses detalhes sem evidências diretas criaria uma precisão operacionalmente perigosa. Este artigo, portanto, não faz nenhuma promessa de relógio específico da plataforma.
Se eventos próximos a um limite de salto forem importantes, preserve a documentação do relógio de origem e os valores brutos. Dois sistemas com tratamento diferente podem discordar mesmo depois de ambos os valores serem formatados como UTC. A conversão por si só não pode reconciliar o seu comportamento de amostragem ou recuperar uma distinção de escala omitida.
A escolha de um tempo de execução também pode afetar a ordem de curta duração do evento. Preserve contadores monotônicos ou dados de sequência específicos da fonte quando essa distinção for importante operacionalmente.
O comportamento do passo do relógio e da mancha é específico da plataforma e não é verificado aqui
Insira 1,483,228,799 segundos: o resultado verificado de ISO é `2016-12-31T23:59:59.000Z`. Aumente a entrada uma vez para 1,483,228,800: o resultado é `2017-01-01T00:00:00.000Z`. Subtrair os inteiros resulta em um, correspondendo à progressão exibida neste modelo.
As linhas locais podem mostrar datas ou deslocamentos diferentes dependendo do navegador, mas derivam desses mesmos instantes. Use as linhas ISO para a verificação de limite. Uma alteração na zona local não está relacionada à existência de um rótulo de segundo bissexto.
O par é um teste de regressão útil porque não há dependência de localidade nas strings ISO. Ele bloqueia diretamente o comportamento do conversor na borda relevante.
Exemplo resolvido: o limite 2016 testado do repositório
A pasta de trabalho fazia referência a uma resolução 2022 e a um prazo futuro. Nenhum padrão ou fonte de política faz parte da evidência de implementação, portanto, nem a data nem a previsão são afirmadas aqui. A política de cronometragem pode mudar e merece uma citação oficial no momento da publicação.
A omissão dessa afirmação não enfraquece a orientação do software. Os dados existentes ainda precisam documentar sua escala, unidade e fonte de relógio. O comportamento atual de um conversor permanece testável independentemente de decisões sobre práticas futuras em tempo civil.
Os mantenedores podem adicionar contexto político posteriormente, citando diretamente a resolução. Até então, excluir um prazo é mais preciso do que publicar uma garantia futura sem respaldo.
As futuras resoluções políticas são omitidas sem uma fonte autorizada
TAI, GPS e outras escalas podem representar o tempo de maneira diferente, mas ToolAcre não oferece nenhum seletor ou tabela de deslocamento para elas. Colar essa contagem como segundos Unix apenas aplica a interpretação do estilo 1970 POSIX. Um resultado legível ainda pode estar semanticamente errado.
Transforme outras escalas com uma fonte que defina sua origem e relacionamento no instante relevante e, em seguida, inspecione o valor Unix resultante. Não adicione uma constante lembrada: os relacionamentos que envolvem o histórico de saltos são exatamente onde a aritmética sem fontes se torna frágil.
A ausência de um modo é visível nas três opções de unidades da IU. Nenhuma altera a escala de tempo; automático apenas seleciona entre duas resoluções Unix.
Outras escalas de tempo estão fora da implementação deste conversor Unix
Para este conversor, a regra verificada é uma etapa direta de 23:59:59 para 00:00:00 no limite testado. Esse modelo suporta aritmética de época comum e explica por que nenhuma saída `:60` aparece. Ele não certifica como o relógio do sistema operacional se comportou enquanto o limite real passava.
Quando a precisão no tratamento do salto é importante, a conversão é a última etapa da apresentação, não a fonte da evidência. Colete primeiro a documentação em escala de relógio, o comportamento de sincronização e os campos de eventos brutos. ToolAcre pode então mostrar o que significa uma contagem Unix declarada em seu modelo testado.
Para registros comuns fora dos limites de salto, essa nuance raramente muda de exibição. Perto de limites sensíveis, no entanto, nomear o modelo evita falsas alegações de fidelidade do segundo físico.