AZ Tools

Conversor de épocas (Unix, FILETIME, Excel)

Tempo

Diferentes sistemas operacionais e apps medem o tempo como 'segundos (ou alguma unidade) desde algum ponto zero escolhido' — mas cada um escolheu diferente. Unix pegou 1970-01-01 UTC. NTP pegou 1900-01-01 UTC. Windows NT pegou 1601-01-01 UTC e conta em intervalos de 100 ns (FILETIME). Os ticks do .NET DateTime contam intervalos de 100 ns desde 0001-01-01. O Mac OS clássico HFS+ usou 1904-01-01 em segundos. Cocoa CFAbsoluteTime da Apple usa 2001-01-01 em segundos. Excel para Windows conta dias desde 1899-12-30 (porque o Lotus 1-2-3 tratou 1900 como ano bissexto por engano e o Excel herdou o bug); Excel para Mac conta a partir de 1904-01-01. Depois há os formatos legíveis: ISO 8601 ('2026-06-05T00:00:00.000Z') e RFC 2822 ('Fri, 05 Jun 2026 00:00:00 GMT'). Quando um BIGINT do SQL Server, uma entrada do log de eventos do Windows e um CSV do Numbers descrevem todos o mesmo momento, você precisa traduzir entre eles. Esta ferramenta faz isso de uma vez — escolha um formato à esquerda, cole o valor e todos os outros são renderizados instantaneamente com o offset de época e unidade corretos. Aritmética BigInt é usada para FILETIME e ticks .NET para que a precisão sobreviva mesmo para datas distantes que estourariam o float de 53 bits do JavaScript.

Momentos de referência
Todos os formatos
ISO 8601
String ISO 8601 data-hora em UTC
2026-06-10T04:05:26.470Z
RFC 2822
String RFC 2822 / HTTP date em GMT
Wed, 10 Jun 2026 04:05:26 GMT
Unix (segundos)
época 1970-01-01 UTC · segundos
1781064326.47
Unix / JS (ms)
época 1970-01-01 UTC · milissegundos
1781064326470
NTP (segundos)
época 1900-01-01 UTC · segundos
3990053126.47
Windows FILETIME
época 1601-01-01 UTC · intervalos 100 ns
134255379264700000
.NET Ticks
época 0001-01-01 UTC · intervalos 100 ns
639166611264700000
Mac HFS+ (segundos)
época 1904-01-01 UTC · segundos
3863909126.47
Apple Cocoa
época 2001-01-01 UTC · segundos (CFAbsoluteTime)
802757126.47
Serial Excel 1900
época 1899-12-30 · fração de dia (compat bug Lotus)
46183.1704453
Serial Excel 1904
época 1904-01-01 · fração de dia (Mac Excel)
44721.1704453
Detalhes da conversão

Valor canônico interno: milissegundos JS desde 1970-01-01 UTC (float 53 bits, válido para ~±285 614 anos a partir de 1970). FILETIME e ticks .NET usam aritmética BigInt para preservar precisão inteira exata. Excel 1900 usa offset 25569 (de 1899-12-30 a 1970-01-01) — correto para todas as datas a partir de 1900-03-01 e descarta silenciosamente o 1900-02-29 fantasma do Lotus. Saídas ISO 8601 e RFC 2822 sempre em UTC/GMT.

Como usar

  1. Escolha um formato fonte no menu (padrão: ISO 8601 no agora).
  2. Cole ou digite o valor nesse formato — as 11 representações atualizam instantaneamente.
  3. Troque o formato para converter: o valor exibido preenche a caixa no novo formato.
  4. Use um preset para semear momentos de referência: agora, época Unix (1970), Y2K, Y2038 ou o rollover NTP (2036-02-07).
  5. Clique no botão de cópia de qualquer linha para copiar essa representação.

Perguntas frequentes

Por que o serial Excel 1900 começa em 1899-12-30 e não 1900-01-01?
O Lotus 1-2-3 tratou 1900 como bissexto erroneamente (não é — 1900 ÷ 100 = 19 com resto 0 mas 1900 ÷ 400 ≠ inteiro, então a regra gregoriana o exclui). Quando a Microsoft construiu o Excel copiou o bug do Lotus por compatibilidade, o que significa que o Excel tem um 29 de fevereiro de 1900 fantasma. Para fazer o offset funcionar limpo em todas as datas após 1900-03-01 usamos 25569 (dias de 1899-12-30 a 1970-01-01), que dá resultados corretos para toda data real. Datas antes de 1900-03-01 no Excel ficam fora por um dia, mas são raríssimas na prática.
Por que usar BigInt para FILETIME e .NET Ticks?
FILETIME conta intervalos de 100 ns desde 1601-01-01 UTC. Para um momento por volta de 2100 são ~1.6 × 10¹⁷ — bem acima de Number.MAX_SAFE_INTEGER (~9 × 10¹⁵). Os dígitos inferiores derivam silenciosamente se você guardá-lo como Number JavaScript normal. O mesmo para ticks .NET (~6.6 × 10¹⁷ por volta de 2100). BigInt é o tipo inteiro de precisão arbitrária do JS e preserva cada dígito exatamente, então passar um FILETIME por esta ferramenta devolve exatamente os mesmos dígitos.
O que é o problema Y2038 e afeta sua saída Unix?
Muitos programas C legados armazenam tempo Unix como inteiro com sinal de 32 bits, que estoura em 2³¹ − 1 segundos após 1970 = 03:14:07 UTC de 2038-01-19. Esta ferramenta armazena tempo como milissegundos JS (float 64 bits, válido para ±285 614 anos em torno de 1970), então Y2038 não é problema aqui. Expomos Y2038 como preset para ver como os formatos representam aquele momento. O NTP tem seu próprio rollover em 2036 porque o contador de 32 bits reinicia; também é preset.
Por que Excel 1900 e Excel 1904 ao mesmo tempo?
Excel para Windows usa 1900 como base; Excel para Mac (e Numbers, até recentemente) usa 1904. Uma planilha enviada por email entre um analista Windows e um Mac parecerá correta em cada app mas vai deslocar silenciosamente ~4 anos se os seriais subjacentes forem copiados crus. Ambos formatos são expostos para detectar ou converter entre eles.

Ferramentas relacionadas