Resumo rapido: Unix timestamp conta segundos desde 1 de janeiro de 1970 UTC. Numero de 10 digitos = segundos; 13 digitos = milissegundos. Esse formato vive em log, banco, API REST e cookie de sessao.
Conversor timestamp Unix: segundos desde 1970-01-01 UTC
Em log de servidor, resposta JSON de API ou campo de banco aparece com frequencia um numero tipo 1715000000 onde deveria estar uma data. Isso e Unix timestamp (ou epoch time): segundos decorridos desde 1970-01-01 00:00:00 UTC.
O formato nasceu no Unix nos anos 1970 e virou padrao universal pra registrar instante exato. E compacto, ordenavel como inteiro e neutro em relacao a fuso horario.
Segundos vs milissegundos
O Unix original conta em segundos. C, Python, PHP, Go, Rust: segundos por padrao. JavaScript (Date.now()), Java (System.currentTimeMillis): milissegundos. Em 2026, timestamp em segundos tem 10 digitos, em milissegundos 13.
Trocar um pelo outro produz o bug classico: data caindo em 1970 (interpretou ms como s e dividiu por mil de menos) ou data no ano 50.000 (interpretou s como ms e multiplicou por mil).
UTC, nao horario local
Timestamp e sempre UTC. Elimina ambiguidade de fuso, horario de verao e diferenca regional. Conversao pra fuso local fica na camada de apresentacao; no banco, no log e na API o valor permanece UTC. Misturar fuso na camada de armazenamento e o caminho mais curto pra bug de "uma hora a menos" na virada do dia.
Brasil esta em UTC-3 (horario de Brasilia, sem DST desde o decreto 9.772 de 2019). Pra converter UTC pra Brasilia, subtraia 3 horas. A ferramenta acima ja faz isso.
| Evento | Timestamp | Data UTC |
|---|---|---|
| Epoch (inicio) | 0 | 1970-01-01 00:00:00 |
| Y2K | 946684800 | 2000-01-01 00:00:00 |
| Marco do bilhao | 1000000000 | 2001-09-09 01:46:40 |
| Limite de 32 bits assinado | 2147483647 | 2038-01-19 03:14:07 |
O bug Y2038
Timestamp em int32 com sinal tem teto em 2.147.483.647 segundos — 19 de janeiro de 2038, 03:14:07 UTC. Um segundo depois, o contador estoura pra negativo e o sistema acha que voltou pra dezembro de 1901. E o Y2K38.
CPU moderna usa int64, que empurra o limite pra centenas de bilhoes de anos. O risco real fica em embarcado, firmware antigo, kernel Linux 32 bits, banco com coluna TIMESTAMP de 4 bytes. Vai aparecer em coisas que ninguem lembra que rodam por baixo.
Atalho para identificar a unidade
Em 2026, timestamp em segundos tem 10 digitos. Em milissegundos, tem 13. Se voce ve 16 digitos, costuma ser microssegundos.
ISO 8601: data e hora em texto
Unix e amigavel a maquina, ISO 8601 e o formato textual padrao. 2026-05-13T10:30:00-03:00 = 13 de maio de 2026, 10h30 em Brasilia. O "T" separa data de hora, o sufixo "-03:00" e o offset em relacao a UTC. Sufixo "Z" = UTC puro (Zulu time).
JSON (REST, GraphQL), logs estruturados, PostgreSQL, Date.toISOString() em JS — todos preferem ISO 8601. Resolve a ambiguidade dd/mm/aaaa vs mm/dd/aaaa que ja causou erro contabil entre filial brasileira e matriz americana mais vezes do que da pra contar.
Fusos brasileiros e o fim do horario de verao
O Brasil usa principalmente America/Sao_Paulo como identificador de fuso (formato IANA tz database), correspondente a UTC-3. Esse identificador cobre a maior parte do territorio nacional. Outros fusos brasileiros sao:
- America/Manaus (UTC-4) para Amazonas e Roraima
- America/Rio_Branco (UTC-5) para Acre
- America/Noronha (UTC-2) para o arquipelago de Fernando de Noronha
Ate 2018 o Sudeste e Sul aplicavam BRST (UTC-2) no verao. O decreto 9.772 de abril de 2019 acabou com o horario de verao no Brasil. Sao Paulo, Rio e demais capitais ficam em UTC-3 o ano inteiro. tz database atualizada apos 2019 ja reflete; servidor com tzdata congelada em 2016 vai errar a hora nos primeiros domingos de novembro a fevereiro.
Onde Unix timestamp aparece
- Logs: nginx, Apache, syslog gravam em segundos UTC pra alinhar registros entre maquinas em fusos diferentes.
- APIs REST e GraphQL:
created_at,updated_atchegam como inteiro em Stripe, Twitter/X, Discord, GitHub. - Bancos: PostgreSQL
timestamp with time zonearmazena UTC internamente. MySQLTIMESTAMPidem. SQLite costuma usar inteiro Unix direto. - Auditoria e financeiro: blockchain, log de pagamento e trilha de auditoria exigem timestamp imutavel em UTC pra correlacao internacional.
- JWT: claims
iat(issued at) eexp(expiration) sempre em Unix timestamp em segundos.
Exemplos historicos de Unix timestamp
| Timestamp | Data UTC | Data Brasilia | Contexto |
|---|---|---|---|
| 0 | 1970-01-01 00:00:00 | 31/12/1969 21:00:00 | Epoch (inicio Unix) |
| 1000000000 | 2001-09-09 01:46:40 | 08/09/2001 22:46:40 | "Bilhao" Unix |
| 1234567890 | 2009-02-13 23:31:30 | 13/02/2009 20:31:30 | Marco simbolico |
| 1577836800 | 2020-01-01 00:00:00 | 31/12/2019 21:00:00 | Inicio de 2020 UTC |
| 2147483647 | 2038-01-19 03:14:07 | 19/01/2038 00:14:07 | Limite signed 32 bits (Y2038) |
Tres representacoes do mesmo instante
No dia a dia alterna-se entre tres formas do mesmo momento:
- Unix (1747140000): compacto, neutro, ideal pra banco e API.
- ISO 8601 (2026-05-13T10:00:00-03:00): textual, sem ambiguidade, ideal pra log e JSON.
- Data brasileira (13/05/2026 10:00:00): apresentacao pra usuario final no Brasil.
A ferramenta acima atravessa qualquer caminho entre as tres. Em codigo, mantenha UTC internamente e converta pra fuso local so na exibicao.
Sobre como formatos como ISO 8601 sao publicados oficialmente, veja o que sao RFCs e padroes de internet. A RFC 3339 e o subset de ISO 8601 usado em protocolos de internet.
Timestamp Unix: Perguntas Frequentes
É a contagem de segundos desde 1 de janeiro de 1970 às 00h UTC, usada como referência universal de tempo em sistemas computacionais.
Sistemas Unix tradicionais usam segundos. Linguagens como JavaScript trabalham em milissegundos. O conversor reconhece os dois formatos automaticamente.
Por padrão exibimos em America/Sao_Paulo, com sigla BRT no horário padrão e BRST em períodos de horário de verão, quando aplicável.
O horário de verão foi suspenso por decreto presidencial em 2019, mas o conversor mantém suporte caso seja reativado em alguma região no futuro.
Logs em timestamp Unix evitam ambiguidade de fuso, ordenam eventos de forma consistente e facilitam análise em ferramentas como Elasticsearch e BigQuery.
Sim. O conversor aceita timestamps negativos, que representam datas anteriores ao epoch Unix, embora seja raro em aplicações modernas.