Unix time em uma frase
O Unix time, também chamado de epoch time ou tempo POSIX, é um único número inteiro que conta os segundos a partir da época, 1970-01-01T00:00:00Z. Ele não tem fuso horário, horário de verão nem calendário dentro dele, e é exatamente por isso que bancos de dados, arquivos de log, APIs, tokens JWT e sistemas de arquivos usam esse formato: dois servidores em continentes diferentes gravam o mesmo número para o mesmo momento.
Datas antes de 1970 são números negativos: -1 é 31 de dezembro de 1969 às 23:59:59 UTC. O valor atual é um pouco menor que dois bilhões e cresce 86.400 por dia.
Experimente aqui: Conversor de Unix timestamp
Abrir a página completa da ferramentaSegundos, milissegundos, microssegundos
A definição usa segundos, mas muitos sistemas guardam unidades menores e continuam chamando de Unix timestamp. O jeito mais rápido de diferenciar em 2026 é contar os dígitos, e é assim também que o conversor desta página reconhece a unidade.
Confundir as unidades é o erro mais comum: trate um valor em milissegundos como segundos e você cai em uma data uns 54.000 anos no futuro; trate segundos como milissegundos e você vai parar em janeiro de 1970. Se a data convertida mostra 1970, multiplique por 1.000. Se mostra um ano muito no futuro, divida por 1.000.
| Unidade | Dígitos hoje | Exemplo para o mesmo momento | Origens comuns |
|---|---|---|---|
| Segundos | 10 | 1700000000 | Unix e Linux, PHP time(), MySQL UNIX_TIMESTAMP(), exp e iat do JWT |
| Milissegundos | 13 | 1700000000000 | JavaScript Date.now(), Java System.currentTimeMillis(), muitas APIs JSON |
| Microssegundos | 16 | 1700000000000000 | Internamente no PostgreSQL, algumas ferramentas de Python e de banco de dados |
| Nanossegundos | 19 | 1700000000000000000 | Go time.UnixNano(), rastreamento de alta resolução |
Fusos horários e UTC
O timestamp em si é sempre baseado em UTC; os fusos horários só aparecem quando você transforma o número em uma data de calendário para alguém ler. O mesmo valor 1700000000 é 22:13 em Londres, 19:13 em São Paulo, 17:13 em Nova York e 01:13 do dia seguinte em Istambul. O número não muda nada, só a forma de mostrar.
Por isso a boa prática é guardar timestamps (ou datas em UTC) e converter para a hora local só no último passo, na interface do usuário. Guardar horas locais leva a horas repetidas ou faltando quando os relógios mudam por causa do horário de verão. O conversor mostra cada timestamp na sua hora local, em UTC e em um fuso extra que você escolhe em Mostrar também em, além do ISO 8601 (2023-11-14T22:13:20.000Z) para APIs e do RFC 2822 para cabeçalhos de e-mail.
Um detalhe: o Unix time ignora os segundos bissextos. Todo dia tem exatamente 86.400 segundos, então um timestamp pode ser convertido em data com uma conta simples. Os segundos bissextos foram absorvidos pelos relógios, e não contados no número.
Como converter no Excel e no Google Planilhas
As planilhas contam dias desde 1900 em vez de segundos desde 1970, então você divide pelo número de segundos de um dia e soma a data da época. Formate a célula do resultado como Data ou Data e hora, senão você vai ver um número decimal como 45244,93. No Excel e no Google Planilhas em português, a função se chama DATA e os argumentos são separados por ponto e vírgula, como nas fórmulas abaixo.
O resultado sai em UTC. Para mostrar a hora local, some o fuso em horas dividido por 24, por exemplo -3/24 para Brasília e São Paulo, +3/24 para Istambul ou -5/24 para Nova York no inverno. O Excel não sabe nada de horário de verão, então um fuso fixo fica errado durante metade do ano em muitos países (o Brasil não tem horário de verão desde 2019, então o -3/24 vale o ano todo por aqui); para logs grandes, converta com o modo em lote do conversor.
| Tarefa | Fórmula (timestamp em A2) |
|---|---|
| Segundos para data (UTC) | =A2/86400+DATA(1970;1;1) |
| Milissegundos para data (UTC) | =A2/86400000+DATA(1970;1;1) |
| Data em A2 para segundos | =(A2-DATA(1970;1;1))*86400 |
| Segundos para horário de Brasília (UTC-3) | =A2/86400+DATA(1970;1;1)-3/24 |
Como converter no JavaScript, no Python e no SQL
Toda linguagem e todo banco de dados importante tem funções prontas para isso. Fique de olho na unidade que cada um espera: o JavaScript trabalha em milissegundos, a maioria dos outros em segundos.
| Ambiente | Timestamp atual | Timestamp para data |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(ts * 1000).toISOString() |
| Python | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) |
| PHP | time() | gmdate('Y-m-d H:i:s', $ts) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) |
| PostgreSQL | extract(epoch from now()) | to_timestamp(ts) |
| SQL Server | DATEDIFF_BIG(SECOND, '1970-01-01', SYSUTCDATETIME()) | DATEADD(SECOND, ts, '1970-01-01') |
| SQLite | strftime('%s', 'now') | datetime(ts, 'unixepoch') |
O problema do ano 2038
Muitos sistemas antigos guardam o Unix time como um inteiro de 32 bits com sinal. O maior valor possível é 2.147.483.647, alcançado em 19 de janeiro de 2038 às 03:14:07 UTC. Um segundo depois o número estoura para um valor negativo grande e a data volta para dezembro de 1901. Tudo o que calcula datas no futuro, como financiamentos de 20 anos, certificados ou tarefas agendadas, pode bater nesse limite antes.
Sistemas operacionais, linguagens e bancos de dados modernos usam tempo de 64 bits, que dura bilhões de anos. O risco está em aparelhos embarcados antigos, formatos de arquivo e colunas de banco de dados. No MySQL, por exemplo, o tipo de coluna TIMESTAMP ainda termina em janeiro de 2038, então dados de longa duração ficam mais seguros em colunas DATETIME ou BIGINT. Se você mantém código antigo, procure campos de tempo de 32 bits e colunas int que guardam timestamps.
Valores de referência úteis
- 0 = 1970-01-01 00:00:00 UTC, a própria época.
- 1000000000 = 2001-09-09 01:46:40 UTC, o primeiro timestamp de dez dígitos.
- 1700000000 = 2023-11-14 22:13:20 UTC.
- 2000000000 = 2033-05-18 03:33:20 UTC.
- 2147483647 = 2038-01-19 03:14:07 UTC, o limite dos 32 bits.
- 86400 = um dia, 604800 = uma semana, 3600 = uma hora.