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.
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.
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.
| Unidade | Exemplo (~2026) | Digitos | Usado em |
|---|---|---|---|
| Segundos (s) | 1745000000 | 10 | Unix padrao, banco de dados, logs |
| Milissegundos (ms) | 1745000000000 | 13 | JavaScript (Date.now()), APIs REST |
| Microsegundos | 1745000000000000 | 16 | Performance profiling, bancos HFT |
| Nanossegundos | 1745000000000000000 | 19 | Sistemas 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 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;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
-- 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');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)
| Fuso | Offset UTC | Timestamp 1700000000 = |
|---|---|---|
| UTC / GMT | +00:00 | 14/11/2023 22:13:20 |
| Sao Paulo (BRT) | -03:00 | 14/11/2023 19:13:20 |
| Manaus (AMT) | -04:00 | 14/11/2023 18:13:20 |
| Acre (ACT) | -05:00 | 14/11/2023 17:13:20 |
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:
Recomendacao: BIGINT em milissegundos para sistemas de backend, TIMESTAMPTZ para PostgreSQL.
Diferenca de datas e apenas subtracao — a grande vantagem do timestamp:
ts2 - ts1(ts2 - ts1) / 60(ts2 - ts1) / 3600(ts2 - ts1) / 86400Constantes 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.
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.
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.
| Fuso | Estados | Diferença UTC | Horário de Verão |
|---|---|---|---|
| UTC-5 | Acre (AC), Javari (AM) | UTC − 5 horas | Não adota desde 2008 |
| UTC-4 | Amazonas (AM), Mato Grosso (MT), Mato Grosso do Sul (MS), Rondônia (RO), Roraima (RR) | UTC − 4 horas | Não adota |
| UTC-3 (padrão) | Brasília, São Paulo, Rio de Janeiro e a maioria dos estados | UTC − 3 horas | Suspenso desde 2019 (Decreto 9.772) |
| UTC-2 | Fernando de Noronha (PE), Atol das Rocas | UTC − 2 horas | Não adota |
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.
| Data | Timestamp Unix | Observação |
|---|---|---|
| 01/01/1970 00:00:00 UTC | 0 | Unix Epoch — ponto zero de todos os timestamps |
| 01/01/2000 00:00:00 UTC | 946.684.800 | Bug Y2K — sistemas que usavam 2 dígitos para ano |
| 19/01/2038 03:14:07 UTC | 2.147.483.647 | Bug Y2K38 — maior valor de int32 com sinal |
| 01/01/2100 00:00:00 UTC | 4.102.444.800 | Referê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.
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.