Um colega de equipe me passou este numero: 1752345678, e me perguntou que data era. Dei uma olhada e disse: por volta de 2025-07-12. Alguns segundos depois ele voltou a perguntar — espera, era o de 13 digitos 1752345678901 ou o de 10 digitos 1752345678? Esse e o estado do dia a dia da maioria das pessoas com carimbos UNIX: reconhece de vista, nao sabe ler.

Este guia existe para que da proxima vez que voce ver uma cadeia de 10, 13, 16 ou 19 digitos, voce consiga dizer na hora que dia, hora e segundo ela aponta — e para entender por que a epoca acabou sendo 1970-01-01.

Resumo em 30 segundos

  • 1970-01-01 00:00:00 UTC foi escolhido como epoca UNIX por tres razoes: o proprio UNIX estava nascendo nessa epoca; um inteiro com sinal de 32 bits armazena tempo de forma mais conveniente comecando dai; e escolher um momento fixo no passado facilita alinhar sistemas.
  • Um carimbo de tempo UNIX e o numero de segundos desde esse momento (com decimais para precisao abaixo do segundo). Na pratica voce encontra quatro precisoes comuns: segundos, milissegundos, microssegundos e nanossegundos.
  • A propria contagem de digitos ja indica a precisao: 10 digitos sao segundos, 13 sao milissegundos, 16 sao microssegundos, 19 sao nanossegundos. So com essa regra voce acerta 90% das vezes.
  • Para alternar entre segundos, milissegundos, microssegundos, nanossegundos e datas legiveis quando quiser, salve nos favoritos o nosso Conversor de carimbo de data/hora UNIX.

5 cenarios reais: onde os carimbos aparecem

Cenario 1: um numero de 13 digitos no log do servidor

Voce ve uma linha tipo 1752345678901 INFO request completed em um log de backend. Esse numero e quase certo milissegundos, nao segundos.

Por que: as linguagens de backend mais usadas retornam por padrao Date.now() (JavaScript), System.currentTimeMillis() (Java) ou time.time() * 1000 (Python), todos milissegundos de 13 digitos.

Solucao: cole 1752345678901 no nosso Conversor de carimbo de data/hora UNIX. Ele detecta a precisao automaticamente e mostra a hora UTC e a hora local. Sem a ferramenta, lembre que 13 digitos divididos por 1000 dao cerca de 10 digitos, e 1752345678 corresponde a aproximadamente 2025-07-12.

Cenario 2: um numero de 10 digitos em uma resposta de API

Uma API REST devolve JSON como {"created_at": 1752345678, "expires_at": 1752346400}. Quase certo que sao segundos.

Por que: algumas APIs antigas (sobretudo da era PHP e certas ferramentas Unix) ainda usam segundos, e varias APIs publicas de horario emitem segundos direto.

Solucao: olhe o nome do campo. Se chama unix_timestamp ou epoch_seconds, sao segundos. Se chama created_time_ms ou timestamp_ms, sao milissegundos. Nosso Conversor de carimbo de data/hora UNIX mostra as quatro precisoes de uma vez, entao voce pode conferir no olho.

Cenario 3: os claims iat e exp em um JWT

O payload de um JWT costuma trazer iat: 1752345678 e exp: 1752349278. Ambos sao segundos, nao milissegundos.

Por que: o RFC 7519 (o padrao JWT) define NumericDate como o numero de segundos desde a epoca (com decimais opcionais). Todas as bibliotecas JWT em conformidade usam segundos.

Solucao: decodifique o token com nosso Decodificador JWT. iat e exp sao mostrados em segundos por padrao. Se voce vir um iat de 13 digitos, isso e um sinal de alerta — ou a biblioteca injetou milissegundos por engano, ou uma implementacao fora do padrao esta em jogo.

Cenario 4: ISO 8601 e epoch misturados no banco de dados

Uma armadilha classica: uma coluna guarda uma string ISO 8601 (2025-07-12T10:30:00Z), outra guarda um inteiro epoch (1752345678). Os JOIN que esquecem de unificar unidades ficam lentos, e as comparacoes que ignoram fuso retornam linhas erradas.

Por que: e um residuo de uma decada de scripts de migracao e ORMs. Times diferentes e eras diferentes de codigo deixam os dois formatos convivendo no mesmo schema.

Solucao: tabelas novas armazenam exatamente um formato unico de tempo absoluto. Prefira milissegundos epoch (13 digitos) ou ISO 8601 com fuso (2025-07-12T10:30:00+08:00). Nao misture.

Cenario 5: tres engenheiros em tres fusos

Alguem posta no chat um horario como 2025-07-12 10:30:00. Um colega le como horario de Pequim, outro como UTC, um terceiro como horario do Pacifico dos EUA. A reuniao atrasa oito horas e alguem entra a meia-noite.

Por que: uma string de horario local sem fuso e uma mina na colaboracao entre fusos.

Solucao: em trabalho entre fusos use apenas ISO 8601 com fuso (2025-07-12T10:30:00+08:00) ou epoch (10 ou 13 digitos). Os dois sao absolutos e nao dependem de onde esta o leitor. Como padrao do time, prefira epoch ms — um numero, um formato, sem ambiguidade para quem cola.

4 armadilhas comuns

Armadilha 1: segundos contra milissegundos (a historia Y2K: 2000-01-01 = 946684800 segundos, nao 946684800000)

A armadilha classica: em 2000-01-01, parte do codigo tratou a epoca como milissegundos e calculou 946684800000. Ao converter isso de volta para data, estourou o inteiro com sinal de 32 bits, travando partes de alguns sistemas e jogando outras datas para 1970.

Solucao: a contagem de digitos e sua primeira pista. 10 digitos sao segundos; 13 digitos sao milissegundos. Se o seu codigo mistura unidades, defina constantes como SECOND = 1 e MILLISECOND = 1000 e encaminhe todas as conversoes por elas. Nada de numeros soltos.

Armadilha 2: comparar dois epoch entre fusos e seguro; comparar duas strings locais naive nao e

Dois epoch subtraidos sempre dao uma diferenca real em segundos, independente do fuso. Duas strings locais naive como 2025-07-12 10:30:00 subtraidas dao uma subtracao literal, nao uma diferenca real de tempo, quando os leitores estao em fusos diferentes.

Solucao: persistencia e comparacao entre fusos usam apenas epoch ou ISO 8601 com fuso. Strings locais naive vivem so na camada de UI — nunca para armazenamento, nunca para comparacao.

Armadilha 3: perda de precisao — microssegundos de 16 digitos e nanossegundos de 19 perdem precisao em JavaScript

Number em JavaScript e dupla precisao IEEE 754. O teto de inteiro seguro e Number.MAX_SAFE_INTEGER = 2^53 - 1 ≈ 9.007 × 10^15. Um microssegundo de 16 digitos (ate ~10^16) e um nanossegundo de 19 digitos (ate ~10^19) passam desse limite, entao guardar em um number do JS perde precisao.

Solucao: linguagens de backend como Go, Rust e os inteiros de Python preservam precisao nativamente. O frontend pode exibir, mas ao persistir de volta no servidor passe como strings ("1752345678901234567"). Subtracoes e comparacoes ficam no backend com bigint ou uma biblioteca de datas.

Armadilha 4: overflow de 32 bits — depois de 2038-01-19 03:14:07 UTC, o inteiro com sinal de 32 bits volta

Um inteiro com sinal de 32 bits vai ate 2^31 - 1 = 2147483647 segundos, que e exatamente 2038-01-19 03:14:07 UTC. Alem disso, um time_t de 32 bits volta para negativo e a data do sistema pula para 1901. Isso e Y2K38.

Solucao: linguagens modernas (Go, Rust, Python 3, Node.js, Java) usam inteiros de 64 bits ou precisao maior e nao sao afetadas. Mas sistemas embarcados, mainframes COBOL legados, certos dispositivos IoT e alguns drivers de banco de dados ainda usam time_t de 32 bits. Audite esses caminhos antes de 2038 ou eles repetirao o drama do Y2K a seu modo.

Praticas recomendadas

  1. No seu codigo, use strings ISO 8601 com fuso para tempo absoluto — por exemplo 2025-07-12T10:30:00+08:00. Humanos leem, maquinas parseiam, sem ambiguidade de fuso.
  2. Em transito e armazenamento, use milissegundos epoch (13 digitos) para tempo absoluto. Um numero, um formato, sem ambiguidade entre linguagens. Funciona em payloads JSON, logs, colunas de banco e parametros de URL.
  3. Na frente do usuario, converta para strings de horario local. Use Intl.DateTimeFormat ou uma biblioteca equivalente para localizar tempo absoluto — nunca faca o usuario calcular fuso na mao.
  4. Ao depurar e verificar, salve nos favoritos o nosso Conversor de carimbo de data/hora UNIX. Cole um numero, veja UTC, horario local, ISO 8601, RFC 2822 e quatro precisoes epoch em um segundo. Combine com nosso Decodificador JWT para inspecionar iat/exp e com nosso Gerador de expressoes cron para ler o epoch dos next-run — assim o ciclo de tratamento de tempo se fecha.
  5. Quando os carimbos vierem codificados em URL ou em Base64 (estado OAuth, URLs assinadas, tokens com carimbo), decodifique primeiro com nosso Codificador de texto e depois cole o resultado no Conversor de carimbo de data/hora UNIX para ver o horario legivel.

A dificuldade com carimbos nao esta na aritmetica — esta em misturar precisoes e fusos. Quando seu time se acomoda no par epoch ms + ISO 8601, 90% dos incidentes de fuso deixam de acontecer.

Ainda vale a pena se preocupar com 2038?

Depende de onde voce olha.

Desktops, servidores, mobiles, funcoes em nuvem — time_t de 64 bits e o padrao em todo lugar, e Y2K38 nao e problema nessas plataformas. Linux, macOS, Windows, Go, Rust, Python 3, Node.js e Java sao todos de 64 bits. Em 2038-01-19 nada visivel vai acontecer.

O risco real vive em sistemas embarcados, mainframes COBOL legados, certos dispositivos IoT e alguns drivers de banco ou sistemas de arquivos que ainda usam inteiros com sinal de 32 bits para time_t. Esses dispositivos tem ciclo lento de atualizacao de firmware — cameras de seguranca, roteadores, PLCs industriais, ECUs automotivas sao as categorias de alto risco.

Solucao: se o seu negocio depende de dispositivos ou bibliotecas de terceiros, audite agora sua cadeia de dependencias. Procure time_t, int32_t guardando segundos, schemas MySQL antigos, codigo C embarcado. Atualize o que puder, escreva workarounds onde nao puder e troque o resto antes de 2038.

Assim como nos anos que antecederam o Y2K, o mundo da engenharia fara correcoes em lote dentro de uma janela. Y2K38 tem a sua propria janela — mais curta do que a do Y2K porque dispositivos de 32 bits estao agora espalhados por muitos fabricantes — e o trabalho comeca hoje.

Abra o Conversor de carimbo de data/hora UNIX, cole um valor de milissegundos de 13 digitos e veja a ferramenta detectar a precisao automaticamente e entregar as quatro precisoes mais UTC, horario local, ISO 8601 e RFC 2822 de uma vez. Um clique nos favoritos; uma resposta em um segundo. Da proxima vez que alguem colar 1752345678, voce tera a resposta.