Como Converter Timestamp Unix para Data: Guia Completo para Desenvolvedores

Developer guide to convert unix timestamp to date showing epoch datetime conversion with code examples

Se você já olhou para um número como 1717200000 e se perguntou que data ele representa, não está sozinho. Aprender a converter timestamp unix para data é uma habilidade fundamental para desenvolvedores que trabalham com APIs, bancos de dados e sistemas backend. Um timestamp Unix é simplesmente uma contagem de segundos (ou milissegundos) decorridos desde 1º de janeiro de 1970, às 00:00:00 UTC, um ponto de referência conhecido como época Unix. Este guia apresenta os fundamentos da conversão de data e hora, manipulação de fuso horário e exemplos práticos de código em JavaScript, Python e SQL, para que você pare de adivinhar e comece a converter com confiança.

Pontos Principais:

  • Um timestamp Unix conta segundos desde 1º de janeiro de 1970 UTC (época 0), sendo neutro em relação ao fuso horário por design.
  • Sempre confirme se seu timestamp está em segundos ou milissegundos antes de converter, pois confundir as unidades é a fonte mais comum de bugs.
  • Ajustes de fuso horário devem ser aplicados explicitamente após converter para UTC, não antes.
  • JavaScript, Python e SQL têm funções integradas para conversão unix para data, mas cada um tem suas peculiaridades que você deve observar.

O que é um Timestamp Unix?

Um timestamp Unix representa um momento único e inequívoco no tempo como um número inteiro. O relógio começou a contar em 1º de janeiro de 1970, às 00:00:00 UTC, um momento chamado de "época 0". Cada segundo que passou desde então adiciona um ao contador. Essa simplicidade é exatamente o motivo pelo qual se tornou o formato de tempo universal para sistemas computacionais.

Não há meses, anos bissextos ou ajustes de horário de verão incorporados no próprio número. O timestamp é sempre baseado em UTC, o que significa que o mesmo número se refere ao exato mesmo momento no tempo, independentemente de onde o servidor ou usuário está localizado. Esta é tanto sua maior força quanto a fonte da maioria das confusões dos desenvolvedores em relação ao formato de hora.

Para uma análise mais profunda de como o tempo de época se tornou a base da computação moderna, veja nosso artigo sobre Tempo de Época: A Base dos Timestamps Unix.

Uma distinção importante: nem todos os timestamps Unix contam em segundos. Alguns sistemas, especialmente ambientes JavaScript e muitas APIs REST, usam milissegundos. Um timestamp de 1717200000 está em segundos; 1717200000000 é o mesmo momento em milissegundos. Confundir essas unidades é o bug mais frequente na conversão de data e hora. Antes de escrever uma única linha de código, confirme a unidade que sua fonte usa.

Não tem certeza de qual unidade seu sistema deveria usar? Confira Segundos vs Milissegundos vs Microssegundos: Qual Timestamp Unix Você Deveria Usar? para uma análise prática.

Diagrama mostrando timestamp unix contando segundos desde época 0 em 1º de janeiro de 1970 UTC

Manipulação de Fuso Horário e Bugs Comuns

A conversão de fuso horário Unix é onde a maioria dos desenvolvedores tropeça. O timestamp em si é sempre UTC. O fuso horário só importa quando você exibe ou interpreta esse timestamp para um usuário ou entrada de log. Entender essa distinção previne toda uma categoria de bugs.

Fundamentos do UTC

A RFC 3339 define o formato padrão para representar datetimes UTC em texto (2024-06-01T00:00:00Z). Quando você converte um timestamp Unix para uma string legível, está aplicando um deslocamento de fuso horário a uma base UTC. Um deslocamento positivo como +05:30 (Horário Padrão da Índia) adiciona horas e minutos; um deslocamento negativo como -05:00 (Horário Padrão do Leste dos EUA) subtrai.

Detecção Automática de Fuso Horário

A maioria das linguagens e navegadores modernos pode detectar o fuso horário local automaticamente. Em JavaScript, Intl.DateTimeFormat().resolvedOptions().timeZone retorna o nome do fuso horário IANA (por exemplo, America/New_York). Em Python, o módulo zoneinfo (Python 3.9+) manipula zonas IANA nativamente. Confiar na detecção automática é adequado para fins de exibição, mas nunca confie nela para armazenar ou calcular timestamps.

Bugs Comuns de Deslocamento

  • Tratar hora local como UTC: Se seu servidor está configurado para UTC+2 e você chama datetime.now() sem especificar um fuso horário, obtém uma hora local que parece UTC mas está atrasada em duas horas.
  • Transições de Horário de Verão: Um deslocamento fixo como +01:00 não considera o horário de verão. Use zonas IANA nomeadas (Europe/Berlin) em vez de deslocamentos fixos sempre que possível.
  • Incompatibilidade milissegundo vs. segundo: Passar um timestamp em milissegundos para uma função que espera segundos produz uma data no ano 55000+. Sempre verifique a magnitude do número primeiro.
  • Configurações de fuso horário do banco de dados: MySQL e PostgreSQL podem armazenar e exibir timestamps de forma diferente dependendo do fuso horário da sessão. Armazene timestamps em UTC e converta na camada da aplicação.

Exemplos de Código: JavaScript, Python e SQL

Os trechos a seguir cobrem os cenários mais comuns para conversão unix para data. Cada exemplo usa um timestamp concreto: 1717200000, que corresponde a 1º de junho de 2024, 00:00:00 UTC.

JavaScript: Converter Timestamp Unix

O objeto Date do JavaScript trabalha em milissegundos, então multiplique um timestamp baseado em segundos por 1000 primeiro.

// JavaScript converter timestamp unix para data
const unixSeconds = 1717200000;
const date = new Date(unixSeconds * 1000); // converter para milissegundos

// String UTC
console.log(date.toUTCString());
// Saída: "Sat, 01 Jun 2024 00:00:00 GMT"

// Exibição em fuso horário local (usa fuso horário do navegador/sistema)
console.log(date.toLocaleString("pt-BR", { timeZone: "America/Sao_Paulo" }));
// Saída: "31/05/2024 21:00:00"

// Formato ISO 8601
console.log(date.toISOString());
// Saída: "2024-06-01T00:00:00.000Z"

Observe como o mesmo timestamp é exibido como 31 de maio em São Paulo porque a meia-noite UTC é 21h no horário de Brasília do dia anterior. Isso não é um bug; é o comportamento correto da conversão de fuso horário unix.

Python: Timestamp Unix para Datetime

O módulo datetime do Python fornece métodos limpos e explícitos. Sempre use objetos datetime com fuso horário em código de produção.

from datetime import datetime, timezone
from zoneinfo import ZoneInfo  # Python 3.9+

unix_seconds = 1717200000

# Python timestamp unix para datetime (UTC)
dt_utc = datetime.fromtimestamp(unix_seconds, tz=timezone.utc)
print(dt_utc)
# Saída: 2024-06-01 00:00:00+00:00

# Converter para um fuso horário específico
dt_sao_paulo = dt_utc.astimezone(ZoneInfo("America/Sao_Paulo"))
print(dt_sao_paulo)
# Saída: 2024-05-31 21:00:00-03:00

# Formatar como string legível
print(dt_utc.strftime("%d de %B de %Y às %H:%M UTC"))
# Saída: 01 de June de 2024 às 00:00 UTC

Usar datetime.fromtimestamp() sem um argumento tz retorna um datetime ingênuo (sem fuso horário) no horário local do sistema, o que pode causar bugs silenciosos em ambientes de servidor. Sempre passe tz=timezone.utc como hábito.

SQL: Época para Datetime

Tanto PostgreSQL quanto MySQL suportam conversão direta de época para datetime.

-- PostgreSQL: converter timestamp unix para data
SELECT TO_TIMESTAMP(1717200000) AS data_convertida;
-- Saída: 2024-06-01 00:00:00+00

-- MySQL: conversão unix para data
SELECT FROM_UNIXTIME(1717200000) AS data_convertida;
-- Saída: 2024-06-01 00:00:00
-- Nota: FROM_UNIXTIME usa o fuso horário da sessão. Configure explicitamente:
SET time_zone = '+00:00';
SELECT FROM_UNIXTIME(1717200000);

Para orientação mais profunda sobre armazenar e consultar timestamps em bancos de dados, veja Timestamps Unix em Bancos de Dados: Melhores Práticas para Armazenamento e Consultas.

Casos de Uso Comuns: época para datetime em Sistemas Reais

Entender os fundamentos é uma coisa. Ver como a conversão época para datetime funciona em sistemas reais faz a diferença. Aqui estão três cenários concretos extraídos de padrões comuns de desenvolvimento SaaS.

Estudo de Caso: Parsing de API REST, Armazenamento em Banco de Dados e Logging de Backend

Imagine uma plataforma SaaS de analytics que ingere eventos de uma API REST de terceiros. Cada resposta da API inclui um campo como "event_time": 1717200000. Veja como a equipe lida com isso em cada camada:

1. Parsing da API REST
O serviço backend recebe o payload JSON e imediatamente valida a unidade do timestamp. Como o valor tem 10 dígitos, a equipe confirma que está em segundos (13 dígitos indicariam milissegundos). O serviço Python o converte para um objeto datetime UTC antes de qualquer processamento adicional. Isso garante que funções downstream nunca recebam um inteiro bruto por acidente.

2. Armazenamento no Banco de Dados
A plataforma armazena o valor em uma coluna PostgreSQL do tipo TIMESTAMPTZ (timestamp com fuso horário). A aplicação sempre insere em UTC usando TO_TIMESTAMP(1717200000). Armazenar em UTC significa que quando a empresa expandir para servir usuários em múltiplas regiões, nenhuma migração de dados será necessária. Consultas sempre filtram em UTC e convertem para horário local apenas na camada de apresentação.

3. Logging de Backend
O pipeline de logging anexa uma string UTC ISO 8601 (2024-06-01T00:00:00Z) a cada entrada de log junto com o timestamp Unix bruto. Essa abordagem dupla significa que engenheiros podem ler logs diretamente sem uma ferramenta de conversão, enquanto sistemas de monitoramento automatizados ainda podem fazer aritmética precisa nos valores inteiros. Quando um relatório de bug diz "o erro aconteceu por volta das 9h horário de Tóquio", a equipe converte isso para um intervalo de timestamp Unix e consulta os logs diretamente.

Esse padrão de três camadas (parsear, armazenar em UTC, exibir localmente) é a maneira mais limpa de lidar com conversão de datetime em qualquer sistema de produção.

Dica Rápida: Se você trabalha com bots do Discord ou servidores de comunidade, timestamps Unix também alimentam a formatação nativa de timestamp do Discord. Aprenda como em nosso guia sobre Como Funcionam os Timestamps do Discord e Como Usá-los no Seu Servidor.

Conclusão

Converter um timestamp Unix para uma data legível é simples uma vez que você entende as três regras: o timestamp é sempre UTC, a unidade é segundos ou milissegundos (confirme antes de converter), e deslocamentos de fuso horário são aplicados no momento da exibição, não do armazenamento. Seja escrevendo JavaScript, Python ou SQL, as ferramentas integradas são confiáveis contanto que você as use com argumentos explícitos de fuso horário. Aplique o padrão de três camadas do estudo de caso acima (parsear, armazenar em UTC, exibir localmente) e você evitará as armadilhas mais comuns na conversão de datetime em qualquer sistema SaaS.

Ferramenta conversora de timestamp unix para data no unixtimestamp.app

Converta Qualquer Timestamp Unix Instantaneamente

Cole qualquer timestamp e obtenha a data UTC exata, horário local e detalhamento de fuso horário em um clique. Sem configuração, sem cadastro necessário.

Experimente o Conversor Gratuito em unixtimestamp.app →

Um timestamp baseado em segundos é um número de 10 dígitos (para datas em torno de 2026), enquanto um timestamp baseado em milissegundos tem 13 dígitos. O objeto Date do JavaScript usa milissegundos nativamente. Para converter um timestamp em segundos no JavaScript, multiplique por 1000 antes de passá-lo para new Date(). Misturar as duas unidades é a causa mais comum de datas completamente incorretas.

Este é o comportamento esperado, não um bug. Um timestamp Unix representa um momento UTC. Se a meia-noite UTC cai no dia anterior do calendário para seu fuso horário (por exemplo, UTC 00:00 é 21h de Brasília do dia anterior), a data exibida será diferente. Sempre especifique o fuso horário alvo explicitamente ao formatar para exibição.

Use datetime.fromtimestamp(ts, tz=timezone.utc) do módulo datetime. Isso retorna um objeto datetime UTC com fuso horário. Evite chamar datetime.fromtimestamp() sem um argumento tz, pois usa o fuso horário local do sistema e cria um datetime ingênuo que pode causar erros silenciosos em ambientes de servidor.

Armazene timestamps como TIMESTAMPTZ (PostgreSQL) ou como inteiros UTC. Evite armazenar strings formatadas como "1º de junho de 2024" porque são mais difíceis de consultar, ordenar e comparar. Converta para formato legível apenas na camada da aplicação ou apresentação, mantendo seu banco de dados neutro em fuso horário e portável.

A época Unix de 1º de janeiro de 1970 foi escolhida pelos primeiros desenvolvedores Unix como um ponto de referência conveniente e recente. Não foi um requisito técnico, mas uma decisão prática tomada no início dos anos 1970 quando o Unix estava sendo desenvolvido nos Bell Labs. A data se tornou desde então o padrão universal para medição de tempo em computadores.