Conversor de Datas ISO

Sobre o Conversor de Datas ISO 8601

Formatos de data e hora são um cemitério de padrões incompatíveis: ISO 8601 (formas básica e estendida), RFC 2822, RFC 3339, SQL DATETIME, Unix epoch em segundos / milissegundos / microssegundos / nanossegundos, seriais Excel, Dia Juliano, data semana ISO, data ordinal ISO — e cada sistema lida com fuso horário e segundos intercalares de forma diferente. Este conversor aceita quase qualquer coisa (cole, a ferramenta detecta), depois produz todas as formas comuns simultaneamente, junto com quatro fusos selecionáveis, dia do ano, semana ISO, trimestre, ano bissexto e tempo relativo ('há 3 horas', 'em 2 dias').

Sem chamadas de rede, sem cookies, sem log — pura aritmética no navegador contra a base IANA da sua máquina. Perfeito para debugar logs, testar contratos de API, agendamento entre equipes e exportar para planilhas.

Qual a diferença real entre os formatos ISO 8601 'básico' e 'estendido'?

O formato estendido (o do dia a dia) usa separadores: 2026-05-17T14:30:00.000Z. O básico os remove: 20260517T143000Z. Contêm informação idêntica; o básico foi desenhado para sistemas com conjuntos de caracteres limitados (mainframes, códigos de barras, nomes de arquivo em Windows que proíbem dois pontos). O ecossistema moderno prefere estendido pela legibilidade, mas o básico ainda aparece em logging industrial, timecode SMPTE de broadcast e firmware embarcado. RFC 3339 (o perfil HTTP do ISO 8601) proíbe explicitamente o básico e exige estendido com 'T' ou ' ' como separador e 'Z' ou '+HH:MM' como fuso — por isso a maioria das APIs REST chega ao 2026-05-17T14:30:00Z.

Como a ferramenta detecta se meu número é segundos, milissegundos, microssegundos ou nanossegundos?

Pela ordem de grandeza. Unix epoch em segundos é número de 10-11 dígitos para qualquer data de nossa vida (1e9 ≈ 2001, 5e9 ≈ 2128). Milissegundos acrescentam 3 zeros (1e12 ≈ 2001 em ms). Microssegundos mais 3 (faixa 1e15). Nanossegundos mais 3 (faixa 1e18). O parser checa: abs(n) < 1e11 → segundos; < 1e14 → ms; < 1e17 → µs; senão → ns. Inequívoco para datas entre ~1970 e 5000 d.C. Casos limite: '0' literal é tratado como segundos (1970-01-01 UTC). Número de 13 dígitos é sempre milissegundos. Se você tem epoch real de precisão de segundo de 2086 em diante (>11 dígitos), prefixe com esclarecimento — mas não é problema de 2026.

Por que o tempo relativo diz 'em 2 dias' para uma data claramente a apenas 47 horas?

O tempo relativo arredonda para a unidade inteira mais próxima — 47 horas arredondam para 2 dias porque a unidade maior (dias) está mais próxima de um corte limpo. Lógica de corte: sob 60 segundos → 'agora mesmo' ou 'X segundos'; sob 1 hora → 'X minutos'; sob 1 dia → 'X horas'; sob 30 dias → 'X dias'; sob 1 ano → 'X meses'; senão 'X anos'. Bate com as convenções do Intl.RelativeTimeFormat usadas por navegadores, notificações de SO e a maioria de mensageria. Para aritmética de precisão exata (ex. 'quantos minutos até minha reunião das 15h'), use a saída epoch em segundos e subtraia.

O que é uma data semana ISO e quando usá-la?

Datas semana ISO expressam uma data como 'ano-semana-dia da semana' (ex. 2026-W21-3 = quarta-feira da semana 21 de 2026). Duas peculiaridades: (1) semanas ISO começam na segunda (não no domingo como nos EUA); (2) a semana 1 contém a primeira quinta-feira do ano — significa que 1-3 de janeiro podem pertencer à semana 52 ou 53 do ano ISO anterior. Use para: sistemas de folha de pagamento/timesheet (resumos semanais), planejamento de varejo (52 semanas estáveis/ano), grades de broadcast, sprints que tratam semanas como unidade atômica e gráficos de UTI mostrando 'dias desde a admissão'. Evite para comunicação humana ('marque a reunião para a semana 21' é sem sentido sem calendário).

As quatro colunas de fuso estão sincronizadas ao mesmo instante?

Sim — as quatro colunas renderizam o mesmo instante UTC (o que seu input parseia), só expresso em fusos IANA diferentes. Se você entra 2026-05-17T12:00:00Z, verá 12:00 em UTC, 05:00 em Los Angeles (UTC-7 DST), 08:00 em Nova York (UTC-4 DST) e 19:00 em Ho Chi Minh (UTC+7). O Intl.DateTimeFormat do navegador lida com transições DST, offsets de meia hora e 45 minutos (Índia é UTC+5:30, Nepal UTC+5:45) e mudanças históricas de regras via tzdata IANA empacotada. Útil para agendamento entre equipes, correlação de logs entre regiões e verificar que seu backend escreve strings UTC com sufixo Z em vez de serializar acidentalmente hora local.

Por que o serial Excel não bate com o que o Excel mostra no meu computador?

Excel usa dois sistemas de data e a maioria não percebe. Padrão ('sistema 1900'): dia 1 = 1900-01-01, com o bug famoso de tratar 1900 como bissexto (não era) — adiciona dia fantasma 60 = 1900-02-29 que nunca existiu. Mac legado ('sistema 1904'): dia 1 = 1904-01-01. Este conversor sai contra o sistema Windows 1900 (padrão para novas pastas) mas compensa o bug bissexto ancorando em 1899-12-30, o truque que o próprio Excel usa internamente para produzir matemática correta de 1900-03-01 em diante. Se trabalha em workbook Mac-1904, subtraia 1462 do nosso serial. Para checar qual sistema sua pasta usa: Arquivo → Opções → Avançado → 'Usar sistema de data 1904'.

Para que serve o Dia Juliano e por que é decimal?

O Dia Juliano (JDN) é uma contagem contínua de dias desde meio-dia UTC de 1 de janeiro de 4713 a.C. (a época Juliana proléptica escolhida por astrônomos em 1583 porque precede todo registro histórico sobrevivente). A parte decimal é a fração do dia após meio-dia UTC: .0 = meio-dia, .5 = meia-noite. JDN domina em astronomia, mecânica orbital de satélites e aritmética de datas históricas porque ignora reformas calendáricas (Juliano → Gregoriano em 1582, não adotado por alguns países até o século XX). O JDN de hoje está em torno de 2.460.829. Dia Juliano Modificado (MJD) é JDN − 2.400.000,5, mais curto e usado em telemetria espacial e padrões CCSDS. Se você não está em astronomia ou aeroespacial, provavelmente não precisa — mas mágicos de planilha usam para subtração limpa de datas (delta dias = JDN_b − JDN_a).

Como a ferramenta lida com segundos intercalares e datas anteriores a 1970?

Segundos intercalares: não lida. Tanto o Unix epoch quanto o objeto Date do JavaScript ignoram explicitamente segundos intercalares — todo dia UTC tem exatamente 86.400 segundos. UTC real teve 27 segundos intercalares inseridos desde 1972, então tecnicamente há um offset de ~27 segundos entre o UTC exibido e o tempo atômico 'real'. Importa para: GPS, timestamps de mercado financeiro (pós-MiFID II), medições científicas de alta precisão. Não importa para: logs, timestamps de API, agendamento, qualquer coisa voltada a humanos. Para datas antes de 1970, a ferramenta as trata — valores epoch negativos, datas como 1066-10-14 (Batalha de Hastings) e a.C. funcionam via Date, embora a extensão Gregoriana proléptica signifique que a data exibida pode não bater com o Juliano em vigor então. Para trabalho calendárico histórico-preciso, use uma biblioteca de astronomia.