Timestamp Unix

Como funciona

O tempo Unix é o número de segundos desde 1º de janeiro de 1970 em UTC. O ponto zero foi escolhido por estar convenientemente perto de quando a medida foi criada, e não porque signifique algo em si.

A medida não conta segundos bissextos. Um dia Unix tem sempre exatamente 86 400 segundos, mesmo nos dias em que o UTC ganhou um segundo a mais. Isso mantém a conta simples, e o tempo Unix continua seguindo a data e a hora do UTC. Mas a diferença entre dois timestamps nem sempre é o tempo que de fato passou. Desde 1972 foram inseridos 27 segundos bissextos, que o tempo Unix não conta. Para quase tudo, exceto navegação por satélite, não faz diferença.

A unidade é deduzida pelo tamanho do número. Tudo abaixo de dez bilhões é lido como segundos, o que dura até o ano 2286, e números maiores como milissegundos ou microssegundos. O limite fica ali para que um ano perto do presente seja lido corretamente.

Números negativos vão para antes de 1970 e funcionam do mesmo jeito.

Um contador de 32 bits com sinal se esgota em 19 de janeiro de 2038 às 03:14:07 UTC e depois volta para 1901. É o problema do ano 2038, o mesmo tipo de falha do bug do milênio, só que em binário. Sistemas que contam em 64 bits não são afetados.

Uma data sem fuso no texto é lida como UTC, então o mesmo texto sempre dá o mesmo número, onde quer que seja lido.

Como o número é lido

Espaços e sublinhados no número são removidos antes da leitura. Sem unidade escolhida, o tamanho decide: abaixo de dez bilhões o número é lido como segundos, a partir de dez bilhões como milissegundos e a partir de cem trilhões como microssegundos. Por causa desses limites, um valor em milissegundos anterior a 26 de abril de 1970, ou em microssegundos anterior a 3 de março de 1973, é lido na unidade errada. Nanossegundos não são uma unidade: 1 757 000 000 000 000 000 nanossegundos, que é 4 de setembro de 2025, são lidos como microssegundos e caem no ano 57647; apague os três últimos dígitos.

Exemplo: onde os 32 bits acabam

2³¹ − 1 = 2 147 483 647 é o maior número que cabe em um contador de 32 bits com sinal. Um segundo depois, esse contador marca −2 147 483 648, que corresponde a 13 de dezembro de 1901, às 20 h 45 min 52 s UTC. Momentos além desses dois limites recebem um aviso: 2 147 483 648 dispara o aviso, 2 147 483 647 não.

Datas como texto

Em JavaScript, 2026-09-12T14:30 é lido como horário local, mas 2026-09-12 como UTC, pelo padrão ECMAScript. A ferramenta lê os dois como UTC, então 2026-09-12T14:30 sempre dá 1 789 223 400, que no horário de Brasília são 11 h 30 min.

Datas que não existem são recusadas: 2026-02-30 gera uma mensagem de erro, enquanto o Date do V8, o motor do Chrome e do Edge, a transforma sem aviso em 2 de março. 24:00 é aceito como o fim do dia, como o ECMAScript permite.

Segundos bissextos e o tempo antes de 1970

O POSIX define os segundos desde a Época com uma fórmula e diz expressamente que a relação com o UTC real não é especificada. O ECMAScript diz que não há valor de tempo para um instante dentro de um segundo bissexto. Assim, 2016-12-31T23:59:60Z, o segundo bissexto mais recente, gera a mensagem de erro de horário inexistente, enquanto o segundo anterior dá 1 483 228 799 e a meia-noite seguinte, 1 483 228 800. Segundo o IERS, a diferença entre o tempo atômico, TAI, e o UTC passou de 10 segundos em 1972 para 37 desde 1º de janeiro de 2017, e o Boletim C 72 anuncia que não haverá segundo bissexto no fim de dezembro de 2026.

Para valores negativos, o POSIX deixa a relação indefinida. A ferramenta segue o ECMAScript, que conta para trás com o calendário gregoriano.

Fontes

• POSIX.1-2024 (The Open Group) – 4.19 Seconds Since the Epoch
• ECMAScript Language Specification – Time Values and Time Range
• IERS – Bulletin C
• IERS – Leap_Second.dat (TAI–UTC desde 1972)

Como as ferramentas são verificadas