Timestamps Epoch Explicados: Como o Tempo Unix Funciona (e Por Que Quebra)

17 Jun 2026 1,156 words

Timestamps Epoch Explicados: Como o Tempo Unix Funciona (e Por Que Quebra)

Um timestamp epoch — também chamado de tempo Unix ou tempo POSIX — é o número de segundos que decorreram desde 1 de janeiro de 1970 00:00:00 UTC, excluindo segundos bissextos. É um número inteiro simples que representa um momento preciso no tempo, independente de fusos horários e sistemas de calendário. Esta simplicidade torna-o a forma padrão de os computadores trocarem informações de tempo, mas também tem limitações e armadilhas conhecidas que todo desenvolvedor deve compreender.

Como o Tempo Unix Funciona

O tempo Unix conta a partir da epoch. Um dia equivale a 86.400 segundos (24 × 60 × 60). O timestamp aumenta exatamente um por segundo, independentemente do fuso horário, horário de verão ou anos bissextos.

Timestamp 0        → 1970-01-01 00:00:00 UTC
Timestamp 86400    → 1970-01-02 00:00:00 UTC
Timestamp 1000000  → 1970-01-12 13:46:40 UTC
Timestamp 1782000000 → 2026-06-17 00:00:00 UTC
// JavaScript — obter timestamp Unix atual
const nowInSeconds = Math.floor(Date.now() / 1000);
console.log(nowInSeconds);

// Converter timestamp para data
const date = new Date(nowInSeconds * 1000);
console.log(date.toISOString());
// PHP — obter timestamp Unix atual
echo time();             // segundos desde a epoch
echo microtime(true);    // segundos com precisão de microssegundos

// Converter timestamp para data
echo date('Y-m-d H:i:s', 1782000000);

Segundos vs Milissegundos: Uma Fonte Comum de Erros

Um dos erros mais frequentes relacionados a timestamps é confundir segundos com milissegundos. O Date.now() do JavaScript retorna milissegundos, enquanto o time() do PHP retorna segundos. Muitas bases de dados armazenam timestamps em segundos, e muitas APIs usam milissegundos.

Sistema Unidade Exemplo de Valor Data
Unix / POSIX Segundos 1782000000 2026-06-17
JavaScript Date.now() Milissegundos 1782000000000 2026-06-17
Java System.currentTimeMillis() Milissegundos 1782000000000 2026-06-17
PHP time() Segundos 1782000000 2026-06-17
Python time.time() Segundos (float) 1782000000.123 2026-06-17
// ❌ Errado — tratando milissegundos como segundos
const timestamp = 1782000000; // isto está em segundos
const wrongDate = new Date(timestamp); // interpreta como milissegundos
console.log(wrongDate.toISOString()); // 1970-01-21 — completamente errado

// ✅ Correto — multiplicar por 1000
const correctDate = new Date(timestamp * 1000);
console.log(correctDate.toISOString()); // 2026-06-17
import time
from datetime import datetime

# ❌ Errado — esquecer de dividir milissegundos
millis = 1782000000000
wrong = datetime.fromtimestamp(millis)  # ValueError: year out of range

# ✅ Correto
correct = datetime.fromtimestamp(millis / 1000)
print(correct)  # 2026-06-17 00:00:00

O Problema do Ano 2038

O tempo Unix usa um inteiro signed de 32 bits, que tem um valor máximo de 2.147.483.647. Em 19 de janeiro de 2038 às 03:14:07 UTC, o timestamp atingirá este limite. Um segundo depois, um inteiro signed de 32 bits passa para −2.147.483.648, que corresponde a 13 de dezembro de 1901.

2.147.483.647 → 2038-01-19 03:14:07 UTC (máx. 32-bit signed)
2.147.483.648 → wraps para negativo (underflow)

Sistemas ainda vulneráveis ao Y2038:

  • Sistemas embarcados (roteadores, dispositivos IoT, firmware de automóveis)
  • Bases de dados legadas que armazenam timestamps como INT(10)
  • Kernels Linux antigos em arquiteturas de 32 bits
  • Sistemas de ficheiros que usam timestamps de 32 bits
  • Versões antigas do PHP em builds de 32 bits

Como verificar se um sistema é seguro para Y2038:

# Linux — verificar se time_t é 64-bit
getconf LONG_BIT
# 64 → seguro
# 32 → verificar versão do kernel e libc

# PHP — verificar tamanho do inteiro
php -r 'echo PHP_INT_SIZE;'
# 8 → seguro (64-bit)
# 4 → vulnerável (32-bit)

Os sistemas modernos com time_t de 64 bits podem representar timestamps até cerca de 292 mil milhões de anos no futuro, tornando o Y2038 um não-problema. A maioria dos servidores de produção já executa sistemas operativos de 64 bits, mas sistemas embarcados e legados permanecem em risco.

Segundos Bissextos: A Complexidade Oculta

O tempo Unix ignora segundos bissextos. Por definição, cada dia tem exatamente 86.400 segundos. Mas o tempo astronómico (UT1) ocasionalmente requer um segundo extra — um segundo bissexto — para permanecer alinhado com a rotação da Terra. Quando ocorre um segundo bissexto, o tempo Unix repete o mesmo segundo:

2016-12-31 23:59:59 UTC
2016-12-31 23:59:60 UTC  ← segundo bissexto (não representável em tempo Unix)
2017-01-01 00:00:00 UTC

A maioria das aplicações ignora segundos bissextos porque ocorrem de forma imprevisível (tipicamente uma vez a cada 1-3 anos) e lidar com eles adiciona complexidade significativa. Sistemas que exigem precisão temporal — como plataformas de negociação financeira e observatórios astronómicos — usam TAI (Tempo Atómico Internacional) ou tempo GPS em vez de tempo Unix.

Armadilhas Comuns

Armadilha 1: Usar a Unidade Errada

// API retorna timestamp em segundos
const apiTimestamp = 1782000000;

// ❌ Errado — new Date() espera milissegundos
const date = new Date(apiTimestamp);

// ✅ Correto
const date = new Date(apiTimestamp * 1000);

Armadilha 2: Armazenar como INT(10) no MySQL

-- ❌ Errado — INT(10) transborda aos 2,1 mil milhões (2038)
CREATE TABLE events (
    created_at INT(10) NOT NULL
);

-- ✅ Correto — usar BIGINT ou TIMESTAMP
CREATE TABLE events (
    created_at BIGINT NOT NULL,       -- 64-bit, seguro
    created_at2 TIMESTAMP NOT NULL     -- MySQL trata a conversão
);

Armadilha 3: Assumir que a Hora Local é o Padrão

// ❌ Errado — date() usa o fuso horário padrão do servidor
echo date('Y-m-d H:i:s', $timestamp);

// ✅ Correto — especificar explicitamente UTC
echo gmdate('Y-m-d H:i:s', $timestamp);
echo date('Y-m-d H:i:s', $timestamp); // se o TZ padrão estiver definido para UTC

Armadilha 4: Overflow de Inteiros em JavaScript

Os números em JavaScript são ponto flutuante de 64 bits, mas as operações bitwise tratam-nos como inteiros signed de 32 bits. Isto pode causar erros inesperados semelhantes ao Y2038 mesmo em navegadores modernos.

// Operação bitwise em JavaScript trata como 32-bit
const timestamp = 2500000000; // além do máximo signed de 32 bits
const shifted = timestamp << 1; // ❌ overflow!
console.log(shifted); // -1794967296 (wrap)

Ferramenta Conversor de Epoch

O Epoch / Unix Timestamp Converter no Help2Code fornece visualização ao vivo do timestamp atual em segundos e milissegundos, conversão bidirecional entre valores epoch e datas legíveis, e suporte para fusos horários local e UTC. Use-o para depurar problemas de timestamp, gerar timestamps para testes ou verificar respostas de API. O Timezone Converter também é útil para verificar como timestamps epoch mapeiam para diferentes fusos horários.

Conclusão

Timestamps epoch são uma forma simples e universal de representar momentos no tempo, mas apresentam algumas ressalvas críticas: verifique sempre se está a trabalhar com segundos ou milissegundos, use armazenamento de 64 bits para evitar o problema Y2038 e nunca assuma que o fuso horário padrão corresponde à sua intenção. Use o Epoch Converter para conversões rápidas e mantenha as diretrizes acima em mente ao lidar com timestamps em código de produção.


About this article

Aprenda como timestamps Unix epoch funcionam, por que 2038 é um problema, a diferença entre segundos e milissegundos e como evitar armadilhas comuns.


Related Articles


Related Tools

Help2Code Logo
Menu