Artigo Build·Desenvolvimento·13 min de leitura de leitura

Unix Timestamp (2026): O Que É, Como Funciona e Como Converter em Qualquer Linguagem

Unix timestamp é o formato de data/hora mais usado em programação desde os anos 70. Aparentemente simples, esconde armadilhas: segundos vs milissegundos, fusos, Year 2038. Este guia cobre origem, uso prático em JS/Python/SQL e quando escolher timestamp em vez de data formatada.

Por Vitor Morais

Fundador do MochaLabz · publicado em 17 de abril de 2026

⏱️

Converta timestamps na hora

Cole o número (em segundos ou ms) e veja data/hora em qualquer fuso.

Usar conversor →

Unix timestamp é um dos formatos mais antigos e mais usados de representação de tempo em computação. Inventado nos anos 70 junto com o próprio Unix, continua sendo o padrão de fato em logs de servidor, bancos de dados, APIs REST, arquivos e eventos distribuídos. Em 2026 ele segue vivo por três razões: é compacto (um inteiro), ordenável por comparação simples e universal — o mesmo número representa o mesmo instante em qualquer fuso horário.

Este guia cobre como funciona, conversões nas linguagens mais comuns, fuso horário, o problema de 2038 e quando é melhor usar timestamp em vez de data formatada.

Definição técnica: segundos desde o epoch

Unix timestamp é um número inteiro que representa quantos segundos passaram desde a meia-noite de 1º de janeiro de 1970 UTC — data conhecida como Unix epoch.

0 = 1970-01-01 00:00:00 UTC
1000000000 = 2001-09-09 01:46:40 UTC (“um bilhão”)
1713360000 = 2026-04-17 12:00:00 UTC
-1000 = 1969-12-31 23:43:20 UTC (negativo = antes do epoch)

Contexto

Mesmo em sistemas Windows, o timestamp “Unix” continua sendo usado em APIs REST, JSON, banco de dados e logs. O nome persiste mesmo fora de ambiente Unix — virou padrão universal.

Segundos vs milissegundos: a confusão mais comum

Nem todos os sistemas trabalham com timestamps em segundos. Alguns usam milissegundos (JavaScript), outros microssegundos (alguns logs em C++), e raramente nanossegundos.

Unidade de timestamp por linguagem/sistema
Critério	Unidade padrão	Exemplo (17/04/2026 12:00 UTC)
JavaScript Date.now()	Milissegundos	1713360000000
Python time.time()	Segundos (float)	1713360000.0
Ruby Time.now.to_i	Segundos	1713360000
Go time.Now().Unix()	Segundos	1713360000
PHP time()	Segundos	1713360000
MySQL UNIX_TIMESTAMP()	Segundos	1713360000
Java Instant.toEpochMilli()	Milissegundos	1713360000000

Atenção

Bug clássico: API enviar ms, cliente interpretar como s (timestamp multiplicado por mil aparece em 57.000 AD). Ou o oposto — receber s e interpretar como ms (data vira 1970). Sempre documente unidade usada. Para clareza, nomeie variáveis timestamp_ms ou timestamp_s.

Conversão em JavaScript

// Timestamp atual em ms
Date.now();                         // 1713360000000

// Timestamp em segundos
Math.floor(Date.now() / 1000);      // 1713360000

// De timestamp (ms) para Date
const d = new Date(1713360000000);
d.toISOString();                    // "2026-04-17T12:00:00.000Z"
d.toLocaleString("pt-BR");          // "17/04/2026, 09:00:00" (Brasília)

// De Date para timestamp
const agora = new Date();
agora.getTime();                    // ms
agora.getTime() / 1000;             // s (com fração)

// Parse de string ISO
new Date("2026-04-17T12:00:00Z").getTime();   // 1713360000000

Conversão em Python

from datetime import datetime, timezone
import time

# Timestamp atual em segundos (float)
time.time()                         # 1713360000.123456
int(time.time())                    # 1713360000

# De timestamp para datetime UTC
datetime.fromtimestamp(1713360000, tz=timezone.utc)
# datetime(2026, 4, 17, 12, 0, tzinfo=UTC)

# De datetime para timestamp
dt = datetime.now(timezone.utc)
dt.timestamp()                      # 1713360000.5

# Parse de ISO 8601
datetime.fromisoformat("2026-04-17T12:00:00+00:00").timestamp()

Conversão em SQL

-- MySQL
SELECT UNIX_TIMESTAMP();                          -- agora em s
SELECT UNIX_TIMESTAMP('2026-04-17 12:00:00');     -- converte data
SELECT FROM_UNIXTIME(1713360000);                 -- converte timestamp

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::bigint;          -- agora em s
SELECT TO_TIMESTAMP(1713360000);                   -- converte timestamp
SELECT EXTRACT(EPOCH FROM '2026-04-17 12:00:00'::TIMESTAMP);

-- SQLite
SELECT strftime('%s', 'now');                      -- agora em s
SELECT datetime(1713360000, 'unixepoch');          -- converte timestamp

Conversão em outras linguagens populares

// Go
import "time"
time.Now().Unix()                                   // segundos
time.Now().UnixMilli()                              // milissegundos
time.Unix(1713360000, 0).Format(time.RFC3339)       // "2026-04-17T12:00:00Z"

// Ruby
Time.now.to_i                                       // segundos
Time.now.to_f                                       // segundos com fração
Time.at(1713360000).utc                             // converte

// Java
import java.time.Instant;
Instant.now().getEpochSecond();                     // segundos
Instant.now().toEpochMilli();                       // ms
Instant.ofEpochSecond(1713360000).toString();       // ISO

// PHP
time();                                             // segundos
date("Y-m-d H:i:s", 1713360000);                    // converte

Timestamp e fuso horário: a regra de ouro

Timestamp é sempre UTC. Não existe “timestamp em horário de Brasília”. O mesmo número 1713360000 representa:

12:00:00 UTC em Londres (sem verão)
09:00:00 em São Paulo (UTC-3)
08:00:00 em Nova York (EST, UTC-5)
21:00:00 em Tóquio (UTC+9)

É o mesmo instante. Quem traduz pra fuso local é o código de apresentação (UI). Essa é a razão de guardar timestamps em UTC em toda aplicação global: evita bugs quando usuário está em fuso diferente do servidor.

Dica

Regra universal: armazene em UTC, exiba em fuso local. Se precisar do fuso do usuário, armazene em coluna separada. Nunca misture timestamp com fuso no mesmo número — vira pesadelo em migração.

Year 2038 Problem

Sistemas que guardam timestamp em int32 (4 bytes, número com sinal) têm limite em 2.147.483.647 — que, em segundos desde 1970, vira 19 de janeiro de 2038 às 03:14:07 UTC. Um segundo depois, overflow: número vira -2.147.483.648, que é 13 de dezembro de 1901.

Onde isso ainda importa em 2026:

Embedded systems: dispositivos velhos em indústria, medidores, roteadores baratos.
Bancos de dados legados: aplicações bancárias e governamentais em mainframe.
Protocolos antigos: formatos de arquivo que reservaram 32 bits para timestamp nos anos 90.
APIs terceiras: algumas APIs antigas ainda retornam int32.

Sistemas modernos (desenvolvidos em 2015+) quase todos usam int64, que só estoura em ~292 bilhões de anos.

Vai mais fundo

Se sua aplicação processa dados com timestamps que cruzam 2038 (contratos longos, aposentadoria, eventos previstos muito à frente), audite todos os campos de timestamp agora. Migrar int32 para int64 depois que o bug aparece custa muito mais que migrar proativamente.

Quando usar timestamp vs data formatada

Timestamp (inteiro) vs ISO 8601 (string)
Critério	Timestamp	ISO 8601
Tamanho	8 bytes (int64)	24 bytes (string)
Legibilidade	Não	Sim
Ordenação	Rápida (comparação numérica)	Rápida (string alfabética)
Diferença de datas	Subtração direta	Precisa parsear
Melhor para logs	Sim (compacto)	Sim (legível)
Melhor para API JSON	Médio	Sim (self-documenting)
Melhor para banco	Aceitável (BIGINT)	Melhor (TIMESTAMPTZ)

Uso prático em logs

Logs tradicionais (JSON, Logstash, CloudWatch) geralmente usam timestamp em milissegundos (compatível com JavaScript e Elasticsearch):

{
  "timestamp": 1713360000123,
  "level": "info",
  "message": "User signed in",
  "user_id": 42,
  "duration_ms": 847
}

Uso em banco de dados

A decisão é entre BIGINT (timestamp inteiro) ou TIMESTAMPTZ(tipo nativo de data/hora). Cada um tem trade-off:

BIGINT: compacto, portável entre bancos, fácil de serializar em JSON. Perde legibilidade em SELECT.
TIMESTAMPTZ (PostgreSQL): armazena em UTC internamente, exibe em fuso local, suporta operações de data nativas. Melhor para a maioria dos casos em 2026.
DATETIME sem fuso (MySQL antigo): evite. Ambíguo por natureza.

Duração entre dois timestamps

// JavaScript: diferença em segundos
const inicio = 1713360000000;
const fim    = 1713363600000;
const duracao_ms = fim - inicio;         // 3600000
const duracao_s  = duracao_ms / 1000;    // 3600
const duracao_h  = duracao_s / 3600;     // 1

// Python: diferença com datetime
from datetime import datetime, timezone
dt_inicio = datetime.fromtimestamp(1713360000, tz=timezone.utc)
dt_fim    = datetime.fromtimestamp(1713363600, tz=timezone.utc)
delta = dt_fim - dt_inicio
print(delta.total_seconds())              # 3600.0
print(delta)                              # 1:00:00

Timestamps em URLs e query strings

Timestamp em URL é padrão para cache busting, assinatura de URL temporária e paginação cursor-based. Exemplo:

// Cache busting
https://cdn.example.com/logo.png?v=1713360000

// Assinatura temporária (Amazon S3, Cloudflare)
https://example.com/file.pdf?expires=1713366400&signature=abc123

// Paginação cursor (próxima página após timestamp X)
GET /posts?after=1713360000&limit=20

Erros clássicos com timestamp

Confundir ms e s: resultado datas no ano 57.000 ou em 1970.
Aplicar fuso no timestamp em vez de na exibição: “ajustar” somando/subtraindo UTC offset no número errado.
Serializar Date sem converter: JSON.stringify(new Date()) retorna ISO string, não timestamp. Fique atento em APIs.
Assumir 1 dia = 86400 segundos sempre: em dias de mudança de horário de verão (quando existe), pode ser 23 ou 25 horas.
Guardar timestamp sem indicar unidade: nome do campo created_at não diz se é ms ou s.
Usar int32 em sistema novo: programar o Year 2038 problem em 2026 é negligência.

Segurança: timestamps em tokens e assinaturas

Timestamps são parte essencial de segurança em sistemas distribuídos:

JWT: campos iat (issued at) e exp(expiração) são timestamps em segundos. Validação do token passa por verificarexp > now().
URLs assinadas: cloud storage (S3, R2) embutem timestamp de expiração na assinatura.
Nonce / replay protection: aplicações bancárias rejeitam requests com timestamp muito antigo (evita replay de requisição legítima).
TOTP (2FA): tokens de 6 dígitos são gerados a partir de timestamp atual arredondado para janelas de 30 segundos.

Ferramentas úteis no dia a dia

Conversor de timestamp (MochaLabz): cola número, vê data em qualquer fuso.
epochconverter.com: conversor web clássico.
Comando date no Linux: date -d @1713360000.
Chrome DevTools Console: new Date(1713360000000) mostra data no fuso local.
Postman / Insomnia: funções de script embutem timestamp dinâmico em requests.

Unix timestamp em uma frase

Unix timestamp é um número simples que guarda 50 anos de complexidade por trás: universal, compacto e confiável quando bem usado, mas cheio de armadilhas (ms vs s, fuso, Year 2038) que custam bug em produção. Dominar esses detalhes separa dev que entende de sistema de dev que só copia exemplo.

Perguntas frequentes

O que é Unix timestamp exatamente?+

Unix timestamp é o número inteiro de segundos decorridos desde a meia-noite UTC de 1º de janeiro de 1970 (o chamado Unix epoch). Por exemplo, o timestamp 1713360000 equivale a 17 de abril de 2026, 12:00:00 UTC. É um formato universal de data/hora usado em bancos, APIs, logs e arquivos desde os anos 70 — e segue sendo o padrão em 2026 por ser pequeno, ordenável e independente de fuso horário.

Por que 1º de janeiro de 1970 foi escolhido como data zero?+

Escolha prática dos engenheiros da Bell Labs nos anos 70: era próximo o suficiente para as máquinas da época representarem datas passadas e futuras em 32 bits sem overflow imediato. Não tem significado técnico especial além disso. O termo “epoch” (época) virou sinônimo dessa data de referência em qualquer sistema Unix-like — Linux, macOS, BSD, Android e derivados.

Timestamp é em segundos ou milissegundos?+

Depende do contexto. Unix original: segundos. JavaScript por padrão: milissegundos (Date.now() retorna em ms). Python time.time(): segundos com fração decimal. MySQL FROM_UNIXTIME: segundos. Ruby Time.now.to_i: segundos. A confusão ms vs s é o bug mais comum em integração de APIs. Regra prática: se o número tem 10 dígitos em 2026, é segundos; 13 dígitos, é milissegundos.

Como o timestamp lida com fuso horário?+

Timestamp é sempre UTC. Isso é o ponto forte dele: o mesmo número representa o mesmo instante em qualquer lugar do mundo. Quem aplica fuso é o código de apresentação, convertendo UTC para o fuso do usuário na hora de exibir. Armazenar em timestamp UTC e converter pra local apenas na UI é a prática recomendada em todo sistema moderno.

O que é o Year 2038 Problem?+

Sistemas que usam int32 para timestamp têm limite em 2147483647 segundos desde 1970, que cai em 19 de janeiro de 2038 às 03:14:07 UTC. Depois disso, overflow gera datas negativas (retorna a 1901). Sistemas modernos (2010+) já usam int64, que só “estoura” em 292 bilhões de anos. Mas sistemas legados em embarcados, bancos antigos e mainframes ainda são vulneráveis. Audite antes de 2035.

Quando usar timestamp e quando usar data formatada?+

Timestamp (inteiro) para armazenamento, cálculos, ordenação, diferenças, logs e APIs entre sistemas. Data formatada (string ISO 8601 ou nativa) para exibição ao usuário, interfaces humanas e alguns contextos de banco que preferem TIMESTAMPTZ nativo. No banco, TIMESTAMPTZ do PostgreSQL já guarda em UTC nos bastidores — o melhor dos dois mundos.

Timestamp pode ser negativo?+

Sim. Datas anteriores a 1º de janeiro de 1970 têm timestamp negativo. Por exemplo, -2208988800 = 1º de janeiro de 1900. Algumas linguagens tratam OK (Python, JavaScript); outras podem ter bugs sutis em sistemas legados. Se você trabalha com dados históricos (genealogia, arquivos antigos), teste explicitamente timestamps negativos.

Qual a diferença entre Unix timestamp e ISO 8601?+

Unix timestamp é número inteiro (1713360000). ISO 8601 é string legível (2026-04-17T12:00:00Z). Timestamp é mais compacto e rápido para comparar/ordenar; ISO é legível para humanos e self-explaining em logs. APIs modernas frequentemente usam ISO 8601 em JSON por ser legível; sistemas de alta performance ainda preferem timestamp. Ambos representam a mesma informação.

#timestamp#unix#epoch#javascript#python#sql#utc#fuso horário#year 2038#data