O tempo epoch explicado: o que é o timestamp Unix zero?

O que o timestamp Unix 0 representa

Todo timestamp Unix conta o tempo decorrido desde um único ponto de referência: 1 de janeiro de 1970 às 00:00:00 UTC. Na definição original do Unix a unidade é o segundo, então o timestamp 0 é exatamente a meia-noite UTC de 1 de janeiro de 1970, e o timestamp 86400 exatamente 24 horas depois. Sistemas modernos também usam milissegundos, microssegundos e nanossegundos, mas o ponto de referência é o mesmo. Todo valor positivo representa um momento após o epoch; todo valor negativo, um anterior.

Por que 1 de janeiro de 1970?

A data foi escolhida pelos desenvolvedores do Unix na Bell Labs no início dos anos 1970 como um ponto de referência prático, pouco antes da criação do próprio Unix. Precisava ser cedo o bastante para que os timestamps normais do sistema fossem positivos, recente o bastante para caber nos pequenos intervalos de inteiros dos primeiros computadores, e simples o bastante para verificar de cabeça. Quando o Unix se tornou influente, linguagens, sistemas operacionais, bancos de dados, formatos de log e protocolos de rede herdaram o mesmo ponto de partida.

• O Unix foi desenvolvido na Bell Labs a partir de 1969 — o epoch foi fixado pouco antes
• 1 de janeiro foi escolhido como um limite de calendário limpo
• 1970 em vez de 1969 porque a implementação usava um contador começando do zero
• Todo SO, linguagem e protocolo moderno herdou esse epoch — não há um padrão concorrente

Timestamps negativos: datas anteriores a 1970

Timestamps Unix negativos representam momentos anteriores a 1 de janeiro de 1970 00:00:00 UTC. A maioria dos sistemas modernos de 64 bits os suporta corretamente, o que é útil para dados históricos, datas de nascimento, registros de arquivo e interoperabilidade com sistemas cujos epochs começam antes do Unix. Bibliotecas e bancos antigos podem rejeitar valores negativos, então conjuntos de dados históricos merecem uma verificação explícita de compatibilidade.

• -1 = December 31, 1969 23:59:59 UTC (one second before the epoch)
• -86400 = December 31, 1969 00:00:00 UTC (one day before the epoch)
• -2208988800 = January 1, 1900 00:00:00 UTC
• JavaScript: new Date(-86400 * 1000).toISOString() → '1969-12-31T00:00:00.000Z'

Limites práticos do formato

O epoch Unix em si não é o limite; o tipo de armazenamento é. Um timestamp guardado em um inteiro com sinal de 32 bits falha muito antes de um guardado em um inteiro de 64 bits, um número JavaScript ou um tipo de timestamp nativo de banco. Ao avaliar a segurança de um timestamp, pergunte tanto qual unidade é usada quanto qual tipo numérico o armazena.

• 32-bit signed integer max: 2,147,483,647 = January 19, 2038 03:14:07 UTC (the Year 2038 problem)
• JavaScript Date max: 8,640,000,000,000,000 ms = September 13, 275760 CE
• 64-bit signed integer max: ~9.2 × 10^18 seconds = year ~292 billion
• PostgreSQL TIMESTAMPTZ max: January 1, 294276 CE

Os epochs de outros sistemas

O Unix não é o único epoch usado em computação. Outros sistemas definiram seus próprios pontos de referência por razões históricas ou técnicas.

• Epoch do GPS: 6 de janeiro de 1980 00:00:00 UTC — usado por satélites e receptores GPS
• Windows FILETIME: 1 de janeiro de 1601 00:00:00 UTC — intervalos de 100 nanossegundos
• Apple Cocoa / NSDate: 1 de janeiro de 2001 00:00:00 UTC
• Excel / Lotus 1-2-3: 1 de janeiro de 1900 — com um bug de ano bissexto deliberado para compatibilidade com o Lotus
• Sistema de arquivos FAT: 1 de janeiro de 1980 00:00:00 hora local

Segundos, milissegundos, microssegundos e nanossegundos epoch

A palavra timestamp nem sempre indica a unidade. Segundos Unix são comuns em sistemas operacionais e linguagens de backend. Milissegundos Unix são comuns em JavaScript e APIs do navegador. Microssegundos e nanossegundos aparecem em bancos, sistemas de tracing e logs de alta resolução. A unidade controla tanto a precisão quanto o número de dígitos que você vê.

• Seconds: 1700000000 — common in Python, PHP, Go, Ruby, C, and Unix command-line tools
• Milliseconds: 1700000000000 — common in JavaScript Date and many web analytics systems
• Microseconds: 1700000000000000 — common in some databases and event pipelines
• Nanoseconds: 1700000000000000000 — common in high-resolution tracing and systems languages
• Always document the unit when storing epoch values in APIs, CSV files, and database columns

Tempo epoch vs UTC vs hora local

O tempo epoch é uma contagem. UTC é o padrão global de tempo que define o momento de referência. A hora local é uma escolha de exibição baseada em um fuso como America/New_York ou Asia/Tokyo. Um timestamp Unix não muda quando um usuário viaja; só mudam a data de calendário e a hora formatadas.

• O mesmo timestamp pode aparecer como datas locais diferentes em fusos diferentes
• A saída UTC é melhor para logs, APIs e depuração entre servidores
• A saída local é melhor para calendários, interfaces e relatórios
• Os deslocamentos de fuso são aplicados na formatação, não armazenados dentro do timestamp Unix

FAQ sobre o tempo epoch

O tempo epoch está sempre em segundos?

O timestamp Unix clássico é em segundos desde 1970-01-01 00:00:00 UTC, mas muitos sistemas usam milissegundos, microssegundos ou nanossegundos com o mesmo epoch.

Os timestamps Unix podem representar datas anteriores a 1970?

Sim. Timestamps negativos representam datas anteriores ao epoch Unix, embora bibliotecas e bancos antigos possam não suportá-los.

Um timestamp Unix inclui um fuso horário?

Não. Um timestamp Unix representa um instante em UTC. A informação de fuso só é usada ao converter esse instante em uma data local legível.

Qual é o timestamp Unix máximo?

Depende do tipo de armazenamento, não do epoch. Um inteiro com sinal de 32 bits vai no máximo até 2,147,483,647 (19 de janeiro de 2038), enquanto um inteiro de 64 bits ou um número JavaScript alcança centenas de milhões de anos. Veja o problema do ano 2038 para detalhes.