💻 Dev / TI · 2026

Timestamp Agora — Conversor Unix Online 2026

Veja o timestamp Unix atual em segundos e milissegundos. Converta para data/hora legível e vice-versa. Suporte a ISO 8601 e fusos horários.

Timestamp agora
segundos · UTC+0
Timestamp → Data
Data → Timestamp

⏰️ O que é Timestamp Unix?

O timestamp Unix (tambem chamado de Unix time, POSIX time ou epoch time) e uma forma universal de representar um instante no tempo como um unico numero inteiro: a quantidade de segundos decorridos desde 1 de janeiro de 1970 as 00:00:00 UTC — o chamado Unix Epoch.

E o padrao mais usado em programacao para armazenar, comparar e transmitir datas e horas, pois elimina ambiguidades de fuso horario, formatos locais e calendarios. Um timestamp e apenas um numero — simples, preciso e universalmente compreendido por qualquer sistema.

📌

Exemplo real: O timestamp 1700000000 corresponde a 14 de novembro de 2023 as 22:13:20 UTC. Em milissegundos: 1700000000000.

🕐 A Historia do Unix Time

O Unix foi desenvolvido entre 1969 e 1971 nos Bell Labs por Ken Thompson, Dennis Ritchie e outros. A data 1 de janeiro de 1970 foi escolhida por ser recente o suficiente para nao gerar numeros negativos em datas usuais. Com inteiros de 32 bits, o sistema representava datas de 1901 a 2038. O padrao foi adotado pelo POSIX em 1988 e hoje e suportado por todas as linguagens e sistemas modernos.

⚠️

Problema do Ano 2038 (Y2K38): Sistemas com inteiros de 32 bits vao transbordar em 19 de janeiro de 2038 as 03:14:07 UTC. A solucao e usar inteiros de 64 bits, o que a maioria dos sistemas modernos ja faz.

📊 Segundos vs Milissegundos vs Microsegundos

UnidadeExemplo (~2026)DigitosUsado em
Segundos (s)174500000010Unix padrao, banco de dados, logs
Milissegundos (ms)174500000000013JavaScript (Date.now()), APIs REST
Microsegundos174500000000000016Performance profiling, bancos HFT
Nanossegundos174500000000000000019Sistemas de tempo real
💡

Identificar a unidade: Em 2026, timestamp em segundos tem 10 digitos. Em milissegundos tem 13 digitos. Contar os digitos e o metodo mais rapido.

💻 Timestamp em Diferentes Linguagens

JavaScript
// Timestamp atual
const ms = Date.now();                    // milissegundos: 1745000000000
const s  = Math.floor(Date.now()/1000);  // segundos:      1745000000

// Timestamp para Date
const d = new Date(1700000000 * 1000);   // multiplica por 1000!
console.log(d.toISOString());            // "2023-11-14T22:13:20.000Z"

// Date para timestamp (segundos)
const ts = Math.floor(new Date("2024-01-01").getTime() / 1000);

// Diferenca entre datas em segundos
const diff = (Date.now() - 1700000000000) / 1000;
Python
import time
from datetime import datetime, timezone

ts = int(time.time())           # segundos: 1745000000
ms = int(time.time() * 1000)   # milissegundos

# Timestamp para datetime (UTC)
dt = datetime.fromtimestamp(1700000000, tz=timezone.utc)
print(dt.isoformat())           # 2023-11-14T22:13:20+00:00

# datetime para timestamp
dt2 = datetime(2024, 1, 1, tzinfo=timezone.utc)
ts2 = int(dt2.timestamp())      # 1704067200
SQL
-- MySQL/MariaDB
SELECT UNIX_TIMESTAMP();                         -- agora
SELECT FROM_UNIXTIME(1700000000);                -- '2023-11-14 22:13:20'
SELECT UNIX_TIMESTAMP('2024-01-01 00:00:00');    -- 1704067200

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW());
SELECT TO_TIMESTAMP(1700000000);

-- SQLite
SELECT strftime('%s','now');
SELECT datetime(1700000000,'unixepoch');
Bash
date +%s                          # segundos agora
date +%s%3N                       # milissegundos agora
date -d @1700000000               # timestamp para data (Linux)
date -r 1700000000                # timestamp para data (macOS)
date -d "2024-01-01" +%s          # data para timestamp (Linux)

🌍 Fusos Horarios e UTC

FusoOffset UTCTimestamp 1700000000 =
UTC / GMT+00:0014/11/2023 22:13:20
Sao Paulo (BRT)-03:0014/11/2023 19:13:20
Manaus (AMT)-04:0014/11/2023 18:13:20
Acre (ACT)-05:0014/11/2023 17:13:20
⚠️

Use nomes de timezone, nao offsets fixos. America/Sao_Paulo e melhor que -03:00 porque lida automaticamente com mudancas de horario de verao. O Brasil aboliu o horario de verao em 2019, mas outros paises ainda mudam.

Perguntas Frequentes

O JavaScript foi criado em 1995 para navegadores, onde precisao de milissegundos e essencial para animacoes e eventos de UI. O Unix padrao usa segundos por ter sido criado para sistemas operacionais. Na pratica: Date.now() retorna ms, entao sempre divida por 1000 para comparar com timestamps em segundos. Esquecer essa conversao e um dos bugs mais comuns ao integrar APIs.

Depende do caso:

  • BIGINT Unix (ms): menos espaco, facil de comparar, independente de fuso. Ideal para eventos, logs e sistemas distribuidos.
  • DATETIME/TIMESTAMPTZ: mais legivel em queries, funcoes nativas do banco. TIMESTAMPTZ do PostgreSQL e excelente — armazena UTC automaticamente.
  • ISO 8601 string: legivel, portavel, mas maior e mais lento para buscas.

Recomendacao: BIGINT em milissegundos para sistemas de backend, TIMESTAMPTZ para PostgreSQL.

Diferenca de datas e apenas subtracao — a grande vantagem do timestamp:

  • Segundos: ts2 - ts1
  • Minutos: (ts2 - ts1) / 60
  • Horas: (ts2 - ts1) / 3600
  • Dias: (ts2 - ts1) / 86400

Constantes uteis: 1 min = 60s | 1h = 3.600s | 1 dia = 86.400s | 1 semana = 604.800s | 1 ano ≈ 31.536.000s.

ISO 8601 e o padrao internacional de datas em texto: 2024-01-15T14:30:00Z. O Z indica UTC; -03:00 indica Sao Paulo.

  • Use ISO 8601 em APIs publicas, JSON de resposta, logs legiveis por humanos.
  • Use Unix timestamp para armazenamento em banco, calculos matematicos, sistemas de alta frequencia.

📌 Referencia Rapida

⏱️

Timestamp agora (2026): ~1.745.000.000s | ~1.745.000.000.000ms. 10 digitos = segundos, 13 digitos = milissegundos.

🌍

Sempre UTC. Use nomes de timezone (America/Sao_Paulo), nunca offsets fixos, para evitar bugs com horario de verao.

⚠️

Y2038: Sistemas com inteiros de 32 bits transbordam em 19/01/2038. Use BIGINT em todos os novos sistemas.

🌍 Fusos Horários do Brasil e UTC

O Brasil possui quatro fusos horários oficiais, o que torna o tratamento de timestamps um desafio recorrente em sistemas nacionais. Um timestamp Unix armazena o tempo em UTC (Tempo Universal Coordenado) sem qualquer informação de fuso — a conversão para horário local deve ser feita na camada de apresentação, nunca no armazenamento. O horário de Brasília (BRT = UTC-3) é o horário de referência do país e o mais utilizado em sistemas comerciais.

FusoEstadosDiferença UTCHorário de Verão
UTC-5Acre (AC), Javari (AM)UTC − 5 horasNão adota desde 2008
UTC-4Amazonas (AM), Mato Grosso (MT), Mato Grosso do Sul (MS), Rondônia (RO), Roraima (RR)UTC − 4 horasNão adota
UTC-3 (padrão)Brasília, São Paulo, Rio de Janeiro e a maioria dos estadosUTC − 3 horasSuspenso desde 2019 (Decreto 9.772)
UTC-2Fernando de Noronha (PE), Atol das RocasUTC − 2 horasNão adota

📅 Timestamps Importantes para Referência

Alguns timestamps Unix têm significâncias históricas ou técnicas especiais. Conhecê-los ajuda no desenvolvimento de sistemas robustos, especialmente ao lidar com datas limites, validações e testes de edge cases. O valor 0 representa a época Unix (Unix Epoch), que é o ponto de partida de todo o sistema de timestamps.

DataTimestamp UnixObservação
01/01/1970 00:00:00 UTC0Unix Epoch — ponto zero de todos os timestamps
01/01/2000 00:00:00 UTC946.684.800Bug Y2K — sistemas que usavam 2 dígitos para ano
19/01/2038 03:14:07 UTC2.147.483.647Bug Y2K38 — maior valor de int32 com sinal
01/01/2100 00:00:00 UTC4.102.444.800Referência para validação de datas futuras distantes
💻

Bug Y2K38 — O próximo grande problema de datas: Sistemas que utilizam inteiros de 32 bits com sinal (int32) para armazenar timestamps Unix atingirão o valor máximo (2.147.483.647) no dia 19 de janeiro de 2038 às 03:14:07 UTC. Após esse momento, o valor transborda para negativo, causando erros de data. A solução é migrar para int64 (que suporta datas até o ano 292.277.026.596). Linux, MySQL 8.0+, PostgreSQL e a maioria dos sistemas modernos já usam timestamps de 64 bits por padrão.

🛠️ Boas Práticas com Timestamps em Sistemas Brasileiros

Ao desenvolver sistemas que atendem usuários em diferentes fusos horários do Brasil, siga estas práticas para evitar bugs difíceis de reproduzir: 1. Sempre armazene timestamps em UTC no banco de dados, nunca em horário local. Isso evita ambiguidades e facilita relatórios que cruzam dados de diferentes regiões. 2. Converta para horário local apenas na apresentação, usando a biblioteca pytz (Python), java.time.ZonedDateTime (Java) ou Intl.DateTimeFormat (JavaScript). 3. Use ISO 8601 para tráfego de dados entre sistemas: formato 2024-03-15T10:30:00-03:00 inclui o offset do fuso e elimina ambiguidades.

4. Cuidado com o horário de verão histórico: Datas anteriores a 2019 no Brasil podem ter tido horário de verão (de outubro a fevereiro, geralmente UTC-2 para a região de Brasília). Ao recalcular horários históricos, use uma biblioteca que inclua o banco de dados de fusos horários da IANA (tz database), que registra todas as mudanças históricas de offset para cada região do mundo. Em Python, zoneinfo (Python 3.9+) e pytz incluem esses dados. 5. Valide intervalos de timestamp na entrada de dados: rejeite timestamps anteriores a 1970 (negativo), muito distantes no futuro (acima de 4 bilhões) ou claramente errôneos para o contexto de negócio.