Gerador de Timestamp Aleatório

Timestamps Unix aleatórios explicados

Um gerador de timestamp Unix aleatório emite valores inteiros que representam instantes absolutos no tempo, sem ambiguidade de fuso horário. O timestamp Unix (também chamado POSIX time ou epoch time) é o número de segundos transcorridos desde 1970-01-01 00:00:00 UTC — a epoch Unix. É a forma canônica de armazenar tempo em bancos de dados, arquivos de log, tokens JWT, cabeçalhos HTTP e qualquer sistema que precise de um valor de relógio portátil e monotônico.

Resoluções: segundos, milissegundos, microssegundos, nanossegundos

Um timestamp pode ser expresso em quatro resoluções comuns. Saber qual o sistema espera é crítico — passar milissegundos para um parser que quer segundos resulta no ano +53000:

• Segundos — 10 dígitos hoje (ex.: 1748390400). Usado por Linux time_t, PHP time(), Postgres EXTRACT(EPOCH FROM ...) e JWT iat/exp.
• Milissegundos — 13 dígitos. Padrão em JavaScript (Date.now()) e Java (System.currentTimeMillis()).
• Microssegundos — 16 dígitos. Usado por Python time.time_ns()/1000 e logs de alta precisão.
• Nanossegundos — 19 dígitos. Go time.Now().UnixNano(), Java Instant.toEpochNano() e traces do OpenTelemetry.

O problema do ano 2038

Um inteiro de 32 bits com sinal só guarda valores até 2^31 − 1 = 2147483647. Como timestamp Unix em segundos, estoura em 2038-01-19 03:14:07 UTC. Um segundo depois, o valor dá a volta para −2147483648, ou seja 1901-12-13. É o problema Y2038. A mitigação foi migrar time_t para inteiros de 64 bits com sinal — empurrando o overflow para o ano 292277026596. A maior parte dos kernels modernos, bancos e linguagens já concluiu a migração; firmware embarcado e COBOL legado ainda são problemáticos.

Conversão entre epoch e ISO 8601

Receita para alternar entre o inteiro Unix e o formato humano ISO 8601 (2026-05-28T15:30:00Z):

JavaScript:  new Date(unix * 1000).toISOString()
Python:      datetime.fromtimestamp(unix, tz=timezone.utc).isoformat()
PHP:         date('c', $unix)
Go:          time.Unix(unix, 0).UTC().Format(time.RFC3339)
SQL (PG):    to_timestamp(unix) AT TIME ZONE 'UTC'

Valores negativos são válidos e representam instantes antes da epoch. O pouso da Apollo 11 em 20 de julho de 1969 cai em torno de -14182940. A maior parte dos parsers aceita negativos; alguns legados tratam como erro.

UTC, leap seconds e sincronização de relógio

UTC (Tempo Universal Coordenado) é o padrão atômico moderno. GMT (Greenwich Mean Time) é o equivalente histórico — mesmo offset, definição formal diferente. O Unix time acompanha o UTC mas com uma peculiaridade: não conta leap seconds. Todo dia em Unix time tem exatamente 86400 segundos, então em dias com leap second o relógio do sistema repete um segundo ou o "esfumaça" ao longo da hora (leap smear). O último leap second foi inserido em 2016-12-31 23:59:60 UTC; o IERS sinalizou que nenhum será emitido até pelo menos 2035.

Servidores se mantêm alinhados com UTC via NTP (Network Time Protocol) sobre UDP porta 123. chronyd e ntpd são os daemons Linux padrão. Um servidor sincronizado corretamente fica tipicamente em 10 ms do UTC real.

Perguntas frequentes

Posso gerar timestamps no passado? Sim — os seletores de data aceitam qualquer intervalo, inclusive antes de 1970 (produz valores negativos).

Segundos ou milissegundos — o que meu sistema quer? JavaScript, Java e a maior parte das APIs JSON usam milissegundos. Syscalls do Linux, Postgres, MySQL UNIX_TIMESTAMP(), JWT e a maior parte de frameworks de log usam segundos. Se o valor tem 10 dígitos é segundos; 13 dígitos é milissegundos.

Para que serve? Semear bancos de teste com colunas created_at/updated_at realistas, gerar streams de log mock para pipelines de ingestão, fuzzing de parsers de data, montar carga de teste com tempos de evento variados, popular fixtures para demos de Grafana/Kibana.

A saída respeita leap seconds? Não — como qualquer timestamp Unix padrão, assume 86400 segundos por dia. Para casos científicos onde leap seconds importam (GPS, astronomia), use TAI (Tempo Atômico Internacional).