O que é um timestamp do Unix?

Um timestamp do Unix é o número de segundos (ou milissegundos) que se passaram desde 00:00:00 UTC de 1º de janeiro de 1970. É uma forma universal e independente de fuso horário para representar um momento específico no tempo.

Como converter uma marcação Unix para uma data legível em JavaScript?

Multiplique o timestamp por 1000 (para converter segundos em milissegundos), em seguida, passe-o para o construtor Date: new Date(timestamp * 1000). Chame .toISOString() ou .toLocaleString() para formatar.

Por que meu timestamp Unix exibe 1970?

Isso geralmente significa que você está passando milissegundos onde segundos são esperados, ou vice-versa. Verifique se seu timestamp é de 10 dígitos (segundos) ou 13 dígitos (milissegundos) e converta conforme necessário.

Os timestamps do Unix são afetados por fuso horário?

Nenhum. Um timestamp Unix sempre representa um momento no fuso horário UTC. Os fusos horários afetam apenas a forma como você exibe ou interpreta esse timestamp na camada da aplicação.

O que é o problema de 2038?

Sistemas que armazenem timestamps do Unix como inteiros assinados de 32 bits ultrapassarão em 19 de janeiro de 2-038. Sistemas modernos utilizam inteiros de 64 bits, que são seguros por bilhões de anos. Sistemas embarcados antigos e esquemas de bancos de dados antigos que utilizam INT(11) para timestamps representam o principal risco.

Anúncios incomodam? Ir Sem anúncios Hoje 

Carimbos de data/hora Unix Como Converter e Por Que Eles São Everywhere

Publicado em 18 abr. 2026

Uma referência prática para trabalhar com timestamps do Unix: segundos versus milissegundos, conversão em JavaScript, Python, SQL e bash, armadilhas com timezone e quando usar timestamps em vez de strings do ISO 860-1.

Timestamps Unix: Como Converter e Por Que Eles São Everywhere 1

ANUNCIADO Remover?

Timestamps Unix: Como Converter e Por Que Eles São Everywhere

Um timestamp Unix é o número de segundos decorridos desde 00:00:00 UTC de 1º de janeiro de 1970 — também chamado de epoch do Unix. Essa data não foi escolhida por razões técnicas; foi simplesmente o ano atual quando o Unix estava sendo projetado. O epoch sempre é UTC, o que significa que um timestamp como 1712800000 representa o mesmo momento em todo o planeta, independentemente do fuso horário.

Os timestamps Unix são usados em todos os lugares: cabeçalhos HTTP, tokens JWT, registros de banco de dados, arquivos de log, filas de mensagens e respostas de APIs. Se você estiver construindo ou debugando algo que envolve tempo, você encontrará esses timestamps constantemente. O Conversor de Timestamp Unix IO Tools é útil para pesquisas rápidas, mas você também precisa saber como lidar com eles no código.

Segundos versus Milissegundos: O Erro que Afeta Todos

O erro de timestamp mais comum em produção: misturar segundos e milissegundos. O padrão Unix usa segundos. A função Date.now() no JavaScript retorna milissegundos. O Java também faz isso com System.currentTimeMillis().

Um timestamp de 1712800000 é abril de 2024. Um timestamp de 1712800000000 (milissegundos) é em algum ano de 56.000. Se seus cálculos de data produzem datas décadas no futuro ou exibem 1970-01-01, isso é quase sempre o motivo.

Regra de ouro: se o timestamp tiver 13 dígitos, é milissegundo. Se tiver 10 dígitos, é segundo. Quando houver dúvida, divida por 1000 e veja se o resultado faz sentido.

Conversão de Timestamps por Linguagem

Aqui estão os padrões que você usará realmente:

JavaScript

// Get current timestamp (milliseconds — divide by 1000 for seconds)
const tsMs = Date.now();           // e.g. 1712800000000
const tsSec = Math.floor(Date.now() / 1000); // e.g. 1712800000

// Convert seconds timestamp to Date object
const ts = 1712800000;
const date = new Date(ts * 1000);  // must multiply by 1000
console.log(date.toISOString());   // "2024-04-11T02:13:20.000Z"

// Convert Date back to Unix timestamp (seconds)
const tsBack = Math.floor(date.getTime() / 1000);

Pitão

from datetime import datetime, timezone

# Get current timestamp (seconds)
import time
ts = int(time.time())  # e.g. 1712800000

# Convert timestamp to datetime (UTC-aware)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat())  # 2024-04-11T02:13:20+00:00

# Convert local-naive datetime to timestamp (risky — see timezone section)
ts_back = int(dt.timestamp())

SQL (MySQL / MariaDB)

-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1712800000);
-- Result: 2024-04-11 02:13:20 (server timezone applies here)

-- Get current Unix timestamp
SELECT UNIX_TIMESTAMP();

-- Convert datetime string to timestamp
SELECT UNIX_TIMESTAMP('2024-04-11 02:13:20');

Bash

# Get current timestamp
date +%s

# Convert timestamp to human-readable (GNU date)
date -d @1712800000
# Output: Thu Apr 11 02:13:20 UTC 2024

# macOS (BSD date)
date -r 1712800000

Tabela de Referência Rápida

Linguagem	Obter o atual (em segundos)	Timestamp → data	Data → timestamp
JavaScript	`Math.floor(Date.now()/1000)`	`new Date(ts * 1000)`	`Math.floor(d.getTime()/1000)`
Pitão	`int(time.time())`	`datetime.fromtimestamp(ts, tz=timezone.utc)`	`int(dt.timestamp())`
MySQL	`UNIX_TIMESTAMP()`	`FROM_UNIXTIME(ts)`	`UNIX_TIMESTAMP(datetime_str)`
Bash	`date +%s`	`date -d @ts`	`date -d "2024-04-11" +%s`

Armadilhas com Fuso Horário

Os timestamps Unix sempre são UTC. Sempre. O número 1712800000 não tem fuso horário — ele apenas conta segundos a partir do epoch. O fuso horário é uma preocupação de exibição, não de armazenamento.

Onde os desenvolvedores ficam em problemas:

Python's datetime.fromtimestamp(ts) sem tz=timezone.utc — usa o fuso horário local do servidor, silenciosamente. Use fromtimestamp(ts, tz=timezone.utc) em vez de.
MySQL's FROM_UNIXTIME() — converte para a configuração de fuso horário do servidor MySQL (@@session.time_zone). Se seu servidor estiver em UTC+8, o resultado desliza em 8 horas.
Armazenar datetime em MySQL sem normalização UTC — se seu servidor de aplicação e o servidor de banco de dados estiverem em fusos horários diferentes, cada inserção e leitura é um erro esperando para acontecer.

O padrão que evita tudo isso: armazene timestamps Unix no banco de dados, converta para formato legível para humanos na camada de exibição do aplicativo, usando o fuso horário preferido do usuário.

Timestamps versus Strings ISO 8601: O Que Armazenar

Ambos são formatos válidos para armazenamento. As vantagens e desvantagens:

Timestamp Unix (inteiro): compacto, rápido para comparações e cálculos, sem ambiguidade de fuso horário, funciona em todos os motores de banco de dados. Desvantagem: não é legível para humanos sem uma ferramenta.
String ISO 8601 (por exemplo, 2024-04-11T02:13:20Z): legível para humanos no banco de dados, auto-documentado. Desvantagem: mais lento para consultas por intervalo, o fuso horário pode ser omitido ou incorreto acidentalmente.

Para a maioria dos aplicativos: armazene timestamps como inteiros. Use strings ISO 8601 em APIs e logs onde a legibilidade para humanos é importante. Se você precisar armazenar ISO 8601, sempre inclua o Z ou offset explícito — um 2024-04-11 02:13:20 sem fuso horário é um desastre em sistemas distribuídos.

O Problema de 2038

Inteiros com 32 bits assinados podem armazenar um valor máximo de 2147483647, o que corresponde a 1º de janeiro de 2038, 03:14:07 UTC. Sistemas que armazenam timestamps Unix em 32 bits int vão ultrapassar esse limite — retornando para 1901 ou travando.

Você deve se preocupar? Se estiver escrevendo código novo, não — use inteiros de 64 bits. Se estiver mantendo código legado em C, firmware embarcado ou esquemas antigos do MySQL usando INT(11) para timestamps, vale a pena auditar. O tipo TIMESTAMP no MySQL também está afetado; DATETIME não está. Sistemas modernos usando timestamps de 64 bits são seguros até o ano de 292 bilhões.

Precisa converter timestamps rapidamente sem escrever código? O Conversor de Timestamp Unix no IO Tools trata segundos e milissegundos, mostra o horário UTC e local lado a lado e permite colar uma data para obter o timestamp de volta.