O que é a época do Unix? Guia do desenvolvedor para carimbos de data/hora

Se você já consultou um banco de dados ou trabalhou com uma API moderna, provavelmente já viu datas retornadas não como "12 de outubro de 2026", mas como uma sequência enorme e intimidante de números como 1791800000. Este é um Timestamp Unix e é a espinha dorsal universal da cronometragem na ciência da computação.

Lidar com datas e horários na programação é notoriamente difícil. Os fusos horários mudam, o horário de verão começa e termina de forma imprevisível e os anos bissextos introduzem dias extras. Para resolver esta realidade caótica, os engenheiros que construíram o sistema operacional Unix decidiram inventar sua própria linha do tempo absoluta.

A Origem: 1º de janeiro de 1970

Um carimbo de data/hora Unix é simplesmente o número de segundos decorridos desde 1º de janeiro de 1970, às 00:00:00 UTC. Este exato momento da história é conhecido como a "Época Unix".

Por que 1970? Porque no início da década de 1970 o armazenamento era incrivelmente caro. Armazenar uma data como uma string legível como "1970-01-01 00:00:00" ocupa quase 20 bytes de memória. Armazená-lo como um único número inteiro de 32 bits consumiu apenas 4 bytes. Ao fazer o ponto de partida próximo ao momento em que o Unix foi inventado, eles maximizaram a quantidade de tempo futuro que poderiam armazenar nesses 4 bytes.

Por que os desenvolvedores adoram carimbos de data/hora Unix

A principal razão pela qual o horário Unix é universalmente adotado em APIs, bancos de dados e microsserviços é que ele não tem fuso horário. Representa um momento único e absoluto no tempo globalmente.

Se você salvar um evento em um banco de dados usando o horário do servidor local ("03:00 PM EST") e depois migrar seu servidor para Londres, todas as suas contas serão interrompidas. Mas se um evento acontecer no carimbo de data/hora 1700000000, esse número será idêntico, quer o usuário que o consulta esteja em Tóquio, Nova York ou Paris. O aplicativo frontend simplesmente pega esse número inteiro e o converte matematicamente para o fuso horário local do usuário na tela.

Segundos x milissegundos (a regra dos 10 x 13 dígitos)

Um dos bugs mais comuns no desenvolvimento web é passar um carimbo de data/hora para uma função e obter uma data no ano 1970 ou no ano 52.000. Isso acontece devido a uma confusão entre segundos e milissegundos.

• Tempo Unix padrão (segundos): um número de 10 dígitos (por exemplo, 1700000000). Este é o padrão em Linux, PHP e na maioria dos bancos de dados backend como MySQL.
• Tempo JavaScript (milissegundos): um número de 13 dígitos (por exemplo, 1700000000000). A função Date.now() do JavaScript inclui milissegundos para maior precisão.

Se você inserir um carimbo de data/hora de back-end de 10 dígitos no JavaScript sem multiplicá-lo por 1.000, o JavaScript assumirá que você está falando dos primeiros dias de janeiro de 1970.

// Correctly handling a Unix timestamp in JavaScript
const backendTimestamp = 1700000000;
const dateObject = new Date(backendTimestamp * 1000);

console.log(dateObject.toLocaleDateString()); // Converts to local user timezone

O problema do ano 2038 (Y2K38)

O tempo do Unix tem um prazo iminente. Como foi originalmente armazenado como um número inteiro assinado de 32 bits, o número máximo que pode conter é 2.147.483.647.

Em 19 de janeiro de 2038, às 03:14:07 UTC, o relógio Unix atingirá esse número máximo. Um segundo depois, o número inteiro irá estourar, passando para um número negativo. Os sistemas legados que não foram atualizados para a arquitetura de 64 bits acreditarão repentinamente que o ano é 1901, causando falhas catastróficas em software em todo o mundo.

Felizmente, quase todos os hardwares, bancos de dados e linguagens de programação modernos (como kernels Linux de 64 bits e Node.js moderno) já fizeram a transição para o tempo de 64 bits, empurrando o próximo overflow para bilhões de anos no futuro.

Perguntas frequentes (FAQ)