Timestamps Unix: as quatro armadilhas que quebram suas datas

Um timestamp Unix é só uma contagem de segundos desde 1970-01-01 UTC. Simples — e ainda assim causa mais bugs de datas que qualquer outro formato. Quatro armadilhas explicam a maioria.

1. Segundos vs milissegundos

Date.now() em JavaScript devolve milissegundos; o tempo Unix clássico e a maioria dos logs usam segundos. Um número de 10 dígitos é segundos, de 13 é milissegundos. Misturá-los transforma 2026 numa data do ano 53.000 — ou de 1970.

2. UTC vs hora local

O timestamp não tem fuso — é o mesmo instante em todo lugar. Os bugs aparecem quando o código converte com o fuso do servidor em vez do do usuário, ou quando uma string como 2026-09-01 08:00 é analisada sem dizer a que fuso pertence.

3. Saltos de horário de verão

Fusos com horário de verão pulam uma hora duas vezes por ano. Uma reunião salva como 09:00 local no verão e no inverno são dois instantes UTC diferentes; guardar UTC e converter só na exibição elimina toda essa classe de bugs.

4. Parsing dependente de locale

03/04/2026 significa 4 de março num país e 3 de abril noutro. Analisar datas de texto exige formato explícito — nunca adivinhe.

Regras práticas: guardar UTC, converter só ao exibir, rotular sempre os formatos. Para inspecionar um timestamp ou data: o conversor de timestamps ou relógios mundiais lado a lado — ambos rodam no navegador.