Por que 1º de janeiro de 1970?

O Bell Labs escolheu essa data como um valor recente e redondo quando o Unix v1 foi lançado em 1971. Versões anteriores usavam 1971-01-01 com ticks de 1/60 de segundo; o estouro de um contador de 32 bits aconteceria em cerca de 2,3 anos, então a equipe mudou para segundos inteiros e retroagiu a época para 1970-01-01 UTC. Foi uma decisão prática, não teológica.

Os segundos intercalares são contados no Unix time?

Não. O POSIX define um Unix timestamp como o número de segundos desde a época assumindo exatamente 86.400 segundos por dia. O UTC real inseriu segundos intercalares ocasionalmente (o mais recente em 30 de junho de 2017). A maioria dos sistemas lida com isso congelando o contador por um segundo ou ’espalhando’ o segundo intercalar ao longo de uma janela maior (abordagem do Google). O resultado: o mesmo Unix timestamp pode corresponder a dois instantes reais diferentes durante um segundo intercalar positivo.

O que exatamente quebra em 2038?

Em 19 de janeiro de 2038 às 03:14:07 UTC, um contador de segundos-desde-a-época de 32 bits com sinal estoura para um número negativo representando 13 de dezembro de 1901. Qualquer sistema de 32 bits, dispositivo embarcado, formato de arquivo ou coluna de banco de dados usando int32 com sinal para hora vai falhar. Linux de 64 bits migrou anos atrás; a exposição restante está em sistemas embarcados, formatos de arquivo legados (timestamps de inode ext2/3, timestamps DOS do ZIP) e colunas SQL declaradas explicitamente como INT.

Devo armazenar timestamps como inteiros ou strings ISO 8601?

Inteiros se você fizer aritmética e o tamanho de armazenamento importar. Strings ISO 8601 se humanos lerão os dados ou você precisar preservar o fuso horário original. Muitos sistemas armazenam ambos — ms de epoch UTC para ordenação e aritmética, mais a string ISO com fuso horário para auditoria. Não armazene números de epoch de hora local; no momento em que um servidor mudar de fuso horário, os dados estarão silenciosamente corrompidos.

Qual é a diferença entre segundos, milissegundos, microssegundos e nanossegundos?

Pura escala. Date.now() do JavaScript retorna milissegundos desde a época. Syscalls Unix como clock_gettime(CLOCK_REALTIME) tipicamente retornam nanossegundos. Os tipos TIMESTAMP de banco de dados variam por fornecedor — Postgres usa microssegundos, MySQL DATETIME(6) usa microssegundos, SQL Server usa ticks de 100ns. Sempre documente a unidade na fronteira da API.

Um Unix timestamp é consciente de fuso horário?

Sim e não. O timestamp em si é uma contagem absoluta de segundos desde um instante UTC fixo, portanto é inequívoco. Mas ele não carrega fuso horário de exibição — converter de volta para uma data de calendário requer a escolha de um fuso horário. Um timestamp de 1700000000 é o mesmo momento físico em todo lugar, mas é renderizado como 14 de novembro em Tóquio e 13 de novembro em Los Angeles.

Guide

Unix Timestamps Explicados: Epoch, Precisão e o Problema do Ano 2038

O formato de hora mais comum do mundo é um hack de 56 anos com um fusível de 12 anos.

By Buğra SözeriPublished May 31, 2026

Um Unix timestamp é um único inteiro que fixa um momento no tempo. É o formato de hora mais amplamente usado na computação — todo banco de dados, linha de log, JWT e cookie HTTP depende dele em última instância. Também está cheio de armadilhas que não se anunciam até que seus dados já estejam errados.

O que é, com precisão

Um Unix timestamp é o número de segundos (ou milissegundos, microssegundos, nanossegundos — escolha uma unidade) que se passaram desde 1970-01-01T00:00:00 UTC, comumente chamado de “a época Unix.” Hoje isso é um número na casa dos 1,7 bilhões para segundos, ou 1,7 trilhão para milissegundos.

Você pode converter um timestamp de e para uma data de calendário com nosso conversor de timestamp — cole qualquer inteiro e veja a data UTC, sua data local e o tempo relativo.

Por que 1970?

A escolha não é profunda. O Bell Labs lançou o Unix v1 em 1971 e precisava de uma data recente arbitrária para o contador de tempo. Um protótipo anterior contava ticks de 1/60 de segundo desde 1971-01-01, mas o contador de 32 bits teria estourado em menos de 2,5 anos. A equipe mudou para segundos inteiros e retroagiu a época para 1970-01-01 para que datas de anos anteriores pudessem ser representadas como números negativos. Ficou assim porque cada sistema downstream o consolidou.

Precisão: segundos, ms, μs, ns

Diferentes camadas da pilha usam unidades diferentes:

Segundos — Unix clássico time(), claims JWT iat/exp, cabeçalhos HTTP Date, maioria das exportações de planilhas.
Milissegundos — JavaScript Date.now(), Java System.currentTimeMillis(), timestamps de registro Kafka, MongoDB ObjectId.
Microssegundos — Postgres TIMESTAMP, MySQL DATETIME(6), bibliotecas de rastreamento (Jaeger, OpenTelemetry).
Nanossegundos — Linux clock_gettime(CLOCK_REALTIME), Go time.Now().UnixNano(), etcd, exportadores recentes do OpenTelemetry.

Em uma fronteira de API, nunca assuma. 1700000000 é novembro de 2023 se lido como segundos, janeiro de 1970 mais 20 dias se lido como milissegundos. Uma heurística rápida: se o inteiro tem aproximadamente 10 dígitos, são segundos; 13 dígitos, milissegundos; 16 dígitos, microssegundos; 19 dígitos, nanossegundos. Nossa ferramenta de timestamp detecta automaticamente todos os quatro.

Segundos intercalares: a mentira no fundo

O POSIX define um Unix timestamp como “segundos desde a época” assumindo explicitamente que cada dia tem 86.400 segundos. O UTC real não faz isso. Desde 1972, 27 segundos intercalares positivos foram inseridos para manter o UTC alinhado com a rotação da Terra. O mais recente foi 30 de junho de 2017.

O comportamento estrito do POSIX é congelar o relógio durante um segundo intercalar: o timestamp 1483228827é servido por dois segundos seguidos. Isso quebra a monotonicidade e trava qualquer coisa que assume que timestamps são únicos. A alternativa do Google, “leap smearing”, distribui o segundo extra ao longo de uma janela de 24 horas para que nenhum segundo individual seja repetido; AWS, Meta e Microsoft agora fazem o mesmo. Dois servidores usando esquemas diferentes podem discordar em até meio segundo ao redor de um evento intercalar.

Para 99% das aplicações isso não importa. Para qualquer coisa que ordena eventos com precisão de sub-segundo em vários provedores, absolutamente importa.

O problema do ano 2038

Um inteiro de 32 bits com sinal pode conter valores de −2.147.483.648 a +2.147.483.647. Interpretado como segundos desde 1970-01-01 UTC, o limite superior é 2038-01-19T03:14:07Z. Um segundo depois, o contador envolve para o valor mais negativo, representando 13 de dezembro de 1901.

Sistemas operacionais modernos de 64 bits já usam time_t de 64 bits, que não estoura por outros 292 bilhões de anos. A exposição que resta:

Dispositivos embarcados — ECUs automotivos, PLCs industriais, implantes médicos. Muitos ainda usam tempo de 32 bits e não são atualizados.
Formatos de arquivo — timestamps de inode ext2/ext3, ZIP clássico (formato DOS), atributos estendidos NTFS mais antigos.
Colunas SQL — uma coluna declarada INTpara “economizar espaço” para segundos de época. Audite seus esquemas agora, não em 2037.
Código C legado compilado contra uma libc antiga em ARM de 32 bits. A migração para time_t de 64 bits é uma quebra de ABI e muitos fornecedores ainda não a fizeram.

Para um tratamento mais longo, veja nossa entrada do glossário de Unix timestamp.

Unix time vs ISO 8601

ISO 8601 (e seu perfil de Internet, RFC 3339) escreve o tempo como 2026-05-31T14:30:00Z. É legível por humanos, consciente de fuso horário e autodescritivo. O Unix time é compacto, ordenável como inteiro e inequívoco sobre o instante real — mas não diz nada sobre qual fuso horário o escritor pretendia para exibição.

Use ISO 8601 em APIs, logs e em qualquer lugar que um humano lerá o valor. Use inteiros Unix no armazenamento quando espaço e aritmética importarem, ou quando a ordenação precisa ser barata. Muitos sistemas carregam ambos — o inteiro para operações, a string para trilhas de auditoria. Veja a entrada do glossário ISO 8601 para a gramática completa.

Armadilhas comuns

Análise sem fuso horário

new Date("2026-05-31") em JavaScript analisa como meia-noite UTC, mas new Date("2026-05-31 14:00") (note o espaço, não um T) é analisado como hora local na maioria dos motores. Os Unix timestamps resultantes diferem pelo seu offset. Sempre inclua o designador de fuso horário (Z, +09:00) em entradas que você não controla totalmente.

Mistura silenciosa de unidades

Um microsserviço que emite milissegundos conversa com um downstream que espera segundos. O downstream vê timestamps no ano 55000 e os grava silenciosamente no banco de dados. Sempre valide a magnitude dos timestamps recebidos em relação a um intervalo plausível.

Épocas de hora local

Alguns sistemas legados calculam “segundos desde 1970-01-01 hora local.” Isso não é Unix time e quebra no momento em que um servidor é movido ou o horário de verão muda. Se você herdar um desses, registre o offset junto com o inteiro e converta para a época UTC verdadeira na fronteira.

Experimente o conversor

Cole qualquer inteiro em nosso conversor de timestamp para ver as interpretações UTC e local lado a lado, com detecção automática de segundos/ms/μs/ns. Para conversão em lote ou controles de precisão extras, a ferramenta de timestamp datetime lida com ambas as direções.

Conclusão

O Unix time é um ótimo padrão porque é compacto, ordenável e inequívoco sobre o instante. É um padrão terrível no momento em que você esquece em qual unidade está, qual fuso horário pretende exibir ou se seu armazenamento é de 32 bits. A época foi uma escolha pragmática em 1970; o penhasco de 2038 é a conta chegando. Audite suas colunas de inteiros, documente suas unidades e não armazene épocas de hora local.

Frequently asked questions

Por que 1º de janeiro de 1970?: O Bell Labs escolheu essa data como um valor recente e redondo quando o Unix v1 foi lançado em 1971. Versões anteriores usavam 1971-01-01 com ticks de 1/60 de segundo; o estouro de um contador de 32 bits aconteceria em cerca de 2,3 anos, então a equipe mudou para segundos inteiros e retroagiu a época para 1970-01-01 UTC. Foi uma decisão prática, não teológica.
Os segundos intercalares são contados no Unix time?: Não. O POSIX define um Unix timestamp como o número de segundos desde a época assumindo exatamente 86.400 segundos por dia. O UTC real inseriu segundos intercalares ocasionalmente (o mais recente em 30 de junho de 2017). A maioria dos sistemas lida com isso congelando o contador por um segundo ou ’espalhando’ o segundo intercalar ao longo de uma janela maior (abordagem do Google). O resultado: o mesmo Unix timestamp pode corresponder a dois instantes reais diferentes durante um segundo intercalar positivo.
O que exatamente quebra em 2038?: Em 19 de janeiro de 2038 às 03:14:07 UTC, um contador de segundos-desde-a-época de 32 bits com sinal estoura para um número negativo representando 13 de dezembro de 1901. Qualquer sistema de 32 bits, dispositivo embarcado, formato de arquivo ou coluna de banco de dados usando int32 com sinal para hora vai falhar. Linux de 64 bits migrou anos atrás; a exposição restante está em sistemas embarcados, formatos de arquivo legados (timestamps de inode ext2/3, timestamps DOS do ZIP) e colunas SQL declaradas explicitamente como INT.
Devo armazenar timestamps como inteiros ou strings ISO 8601?: Inteiros se você fizer aritmética e o tamanho de armazenamento importar. Strings ISO 8601 se humanos lerão os dados ou você precisar preservar o fuso horário original. Muitos sistemas armazenam ambos — ms de epoch UTC para ordenação e aritmética, mais a string ISO com fuso horário para auditoria. Não armazene números de epoch de hora local; no momento em que um servidor mudar de fuso horário, os dados estarão silenciosamente corrompidos.
Qual é a diferença entre segundos, milissegundos, microssegundos e nanossegundos?: Pura escala. Date.now() do JavaScript retorna milissegundos desde a época. Syscalls Unix como clock_gettime(CLOCK_REALTIME) tipicamente retornam nanossegundos. Os tipos TIMESTAMP de banco de dados variam por fornecedor — Postgres usa microssegundos, MySQL DATETIME(6) usa microssegundos, SQL Server usa ticks de 100ns. Sempre documente a unidade na fronteira da API.
Um Unix timestamp é consciente de fuso horário?: Sim e não. O timestamp em si é uma contagem absoluta de segundos desde um instante UTC fixo, portanto é inequívoco. Mas ele não carrega fuso horário de exibição — converter de volta para uma data de calendário requer a escolha de um fuso horário. Um timestamp de 1700000000 é o mesmo momento físico em todo lugar, mas é renderizado como 14 de novembro em Tóquio e 13 de novembro em Los Angeles.

Published May 31, 2026