Como Converter Timestamps Unix

Os timestamps Unix são a forma como os computadores armazenam e comunicam o tempo: um único número que representa segundos desde 1 de janeiro de 1970. Eles aparecem em respostas de API, registros de banco de dados, arquivos de log e tokens JWT. Quando voce precisa saber qual data é realmente 1711824000, voce precisa de um conversor. Um conversor baseado em navegador lida com a matemática instantaneamente e permite voce ir em ambas as direções (timestamp para data, data para timestamp).

Como é um timestamp Unix

A diferença entre segundos e milissegundos é tres zeros extras. Um número de 10 dígitos está em segundos; 13 dígitos é milissegundos. A partir de 2024, todos os timestamps Unix baseados em segundos tem 10 dígitos e permanecerão assim até novembro de 2286.

Como converter timestamps

1. Insira um timestamp ou data: cole um timestamp Unix para converter em uma data legível, ou insira uma data para obter o timestamp.
2. Verifique o formato: o conversor detecta automaticamente segundos vs milissegundos com base no comprimento do número.
3. Leia o resultado: veja a data no seu fuso horário local, UTC e formato ISO 8601.

Uma breve história do tempo Unix

O tempo Unix foi definido pela primeira vez no Manual do Programador Unix publicado na Bell Labs em novembro de 1971. A época original era 1 de janeiro de 1971, mas foi alterada para 1 de janeiro de 1970 logo depois e padronizada em POSIX.1 (1988).

A escolha de 1970 foi arbitrária mas prática: o Unix foi desenvolvido em 1969-1971, e iniciar a contagem perto do nascimento do SO parecia razoável. Um inteiro com sinal de 32 bits contando segundos a partir de 1970 deu uma faixa de dezembro de 1901 a janeiro de 2038, o que os designers acharam que seria suficiente.

Não é. O "problema do ano 2038" (também chamado Y2K38) é o momento em que timestamps Unix com sinal de 32 bits transbordam: 2147483647 segundos após a época, o próximo tique vira para um número negativo que os sistemas interpretam como dezembro de 1901. A maioria dos sistemas modernos migrou para timestamps inteiros de 64 bits nos anos 2000 e 2010, mas alguns dispositivos embarcados, bancos de dados mais antigos e formatos de arquivo legados ainda usam tempo de 32 bits e precisarão de patches antes de 2038.

O tempo Unix é agora o padrão de fato para representar tempo em sistemas computacionais. APIs JSON, timestamps de linhas de banco de dados, expirações JWT, tempos de bloco de blockchain, leituras de sensores IoT: quase todos usam a época Unix direta ou indiretamente.

Segundos, milissegundos, microssegundos, nanossegundos

Sistemas diferentes usam precisões diferentes:

• Segundos (10 dígitos em 2024): tempo Unix clássico, padrão POSIX, a maioria das APIs e bancos de dados
• Milissegundos (13 dígitos): JavaScript Date, Java System.currentTimeMillis(), muitas APIs web
• Microssegundos (16 dígitos): PostgreSQL timestamp, Python datetime (após conversão)
• Nanossegundos (19 dígitos): Go time.UnixNano(), rastreamento eBPF, sistemas de negociação de alta frequencia

Um timestamp de 19 dígitos pode confundir conversores esperando milissegundos; verifique a documentação de origem quando voce vir números anomalos.

Onde voce encontra timestamps

• Respostas de API: a maioria das APIs REST retorna datas como timestamps Unix: "created_at": 1711824000
• Tokens JWT: as reivindicações iat (emitido em) e exp (expiração) são timestamps Unix
• Registros de banco de dados: muitos bancos de dados armazenam timestamps como inteiros para classificação e comparação eficientes
• Arquivos de log: logs de servidor frequentemente prefixam entradas com timestamps de época
• Tarefas Cron: sistemas de agendamento referenciam tempo no formato Unix
• Mtime/atime/ctime do sistema de arquivos: metadados de arquivos Linux e macOS usam tempo Unix
• Timestamps de bloco blockchain: todo bloco Bitcoin e Ethereum tem um timestamp Unix em seu cabeçalho
• Cookies e cabeçalhos HTTP: Max-Age, If-Modified-Since frequentemente usam matemática de época indiretamente

Timestamps em código

Conversão rápida em linguagens comuns:

JavaScript:

new Date(1711824000 * 1000)            // De segundos (multiplicar por 1000)
new Date(1711824000000)                // De milissegundos
Math.floor(Date.now() / 1000)          // Tempo atual em segundos
Date.now()                             // Tempo atual em milissegundos

Python:

from datetime import datetime, timezone
datetime.fromtimestamp(1711824000, tz=timezone.utc)
datetime.now(timezone.utc).timestamp()  # Tempo atual em segundos (float)

Bash:

date -u -d @1711824000                 # GNU date (Linux)
date -u -r 1711824000                  # BSD date (macOS)
date +%s                               # Tempo atual em segundos

SQL (PostgreSQL):

SELECT TO_TIMESTAMP(1711824000);       -- Converter época para timestamp
SELECT EXTRACT(EPOCH FROM NOW());      -- Época atual

Go:

time.Unix(1711824000, 0)               // De segundos
time.Now().Unix()                      // Tempo atual em segundos

Manipulação de fuso horário

É aqui que a maioria dos bugs de timestamp se esconde:

• Timestamps Unix são sempre UTC. Não existe um timestamp Unix de "hora local". O número em si é absoluto.
• Fuso horário de exibição importa. O mesmo timestamp 1711824000 exibe como:
  • 2024-03-31 00:00:00 UTC
  • 2024-03-30 17:00:00 PDT (Los Angeles, UTC-7)
  • 2024-03-31 09:00:00 JST (Tóquio, UTC+9)
• Transições de DST são complicadas. Um horário local como "2024-03-10 02:30:00 EST" não existe (o relógio pulou de 02:00 para 03:00). Conversores lidam com isso de forma diferente; alguns retornam um erro, alguns arredondam para 03:30, alguns mudam para hora padrão.
• Segundos bissextos são ignorados. O tempo Unix finge que cada minuto tem exatamente 60 segundos. UTC real insere segundos bissextos ocasionalmente (o último foi em 2016). Para 99% dos usos, isso é bom; para astronomia de precisão ou relógios atomicos, importa.

Ao enviar timestamps em APIs, use sempre segundos UTC. Ao exibir para usuários, converta para o fuso horário local deles. O conversor lida com ambas as direções.

Armadilhas comuns

• O construtor JavaScript Date() aceita milissegundos, não segundos: o bug de timestamp nº1. new Date(1711824000) interpreta o número como 20 de janeiro de 1970 porque JS o le como milissegundos. Voce precisa de new Date(1711824000 * 1000).
• Confundir tempo Unix e números de data do Excel/Google Sheets: o Excel usa uma época diferente (30 de dezembro de 1899) e conta dias, não segundos. Importar um timestamp Unix em uma coluna de data exibirá a data errada.
• Timestamps negativos: datas anteriores a 1 de janeiro de 1970 são representadas como timestamps Unix negativos. Alguns conversores e bancos de dados os rejeitam; outros os lidam corretamente.
• Ano 2038 em código legado: timestamps inteiros com sinal de 32 bits transbordam em 19 de janeiro de 2038 às 03:14:07 UTC. A maioria dos sistemas modernos usa 64 bits, mas verifique dispositivos embarcados, bancos de dados SQLite antigos e SOs de 32 bits.
• Análise de data dependente de localidade: "03/04/2024" é 4 de março em ingles americano, 3 de abril em ingles britanico. Sempre passe timestamps (ou strings ISO 8601) entre sistemas; nunca strings formatadas por localidade.
• Perda de precisão sub-segundo: armazenar um timestamp de milissegundos em um campo de precisão de segundos perde os últimos 3 dígitos. Algumas APIs retornam ambos os formatos (created_at em segundos, created_at_ms em milissegundos) para evitar isso.

Dicas

• Multiplique por 1000 para JavaScript: JS Date espera milissegundos, mas a maioria das APIs retorna segundos. Esquecer de multiplicar é o bug de timestamp mais comum.
• Especifique sempre UTC: ao converter, seja explícito sobre o fuso horário. "31 de março à meia-noite" é um timestamp diferente dependendo se voce quer dizer UTC, EST ou PST.
• Use ISO 8601 para exibição: uma vez convertido, formate datas como 2024-03-31T00:00:00Z para comunicação inequívoca entre fusos horários.
• Marque o conversor como favorito: se voce trabalha com APIs ou bancos de dados, converterá timestamps com frequencia suficiente para que queira tudo a um clique.
• Ida e volta para verificar: em caso de dúvida, converta seu timestamp em uma data, depois converta a data de volta em um timestamp. Se voce obtiver o mesmo número, seu entendimento está correto.
• Observe o número de dígitos: 10 = segundos, 13 = milissegundos, 16 = microssegundos, 19 = nanossegundos. Se sua matemática estiver errada por um fator de 1000 ou 1000000, voce tem uma incompatibilidade de precisão.

Privacidade

O conversor de timestamp Unix roda inteiramente no seu navegador. Os timestamps e datas que voce insere nunca deixam seu dispositivo. Isso importa porque os timestamps podem ser sensíveis: podem ser de arquivos de log revelando temporização de infraestrutura interna, tokens JWT com informações de usuário/sessão embutidas, depuração interna de API que não deve ser compartilhada com terceiros. Conversores de timestamp em nuvem podem registrar entradas para fins de "melhoria"; um conversor apenas no navegador tem zero exposição.

A conversão baseada em navegador também funciona offline uma vez que a página é carregada, e é rápida o suficiente para que voce possa soltar um timestamp no campo e ver a data no mesmo momento.