Português (Brasil)

Ferramentas para desenvolvedores · Conversor de carimbo de data/hora Unix

ISO 8601 vs RFC 3339: os dois formatos de data por trás de suas respostas API

· Fundo

carimbos de data/hora iso-8601 API

Um amplo funil de formato de data e hora reduzido a um contrato API
Ilustração vetorial original ToolAcre

A maioria das APIs afirma usar ISO 8601 e na verdade usa RFC 3339, um perfil mais rígido projetado para a Internet. Esta postagem explica os dois documentos, suas diferenças e como eles se relacionam com os números inteiros de época.

O campo 'ISO 8601' que rejeita ISO 8601 válido — uma data semanal ou um valor de precisão reduzida enviado para um API que esperava RFC 3339

Um campo API descrito casualmente como “ISO 8601” pode aceitar apenas um formato de data e hora. O envio de outra representação válida para os padrões ainda pode falhar em seu analisador. A solução não é argumentar a partir do nome genérico; é documentar a gramática exata com exemplos e testes de validação.

ToolAcre contribui com uma saída canônica estável de `Date.toISOString()`, mas não é um conjunto de conformidade para todas as representações. Trate a string gerada como um formulário de intercâmbio útil e compare-a com o contrato API que você realmente possui.

Um esquema deve, portanto, publicar uma expressão regular ou um tipo formal somente se refletir com precisão o analisador. Os exemplos por si só são úteis, mas os casos de rejeição explícita encerram a ambiguidade.

Um padrão de data amplo e uma gramática API restrita não são intercambiáveis

O formulário gerado contém data do calendário, `T`, tempo em milissegundos e Z final. A implementação o chama de ISO 8601 (UTC) na UI. A entrada aceita o que JavaScript Date lê, incluindo um deslocamento explícito e o formato de data e hora sem zona do seletor local.

Esse comportamento é muito mais restrito do que um analisador padrão completo. Datas semanais, intervalos, durações e precisão reduzida não possuem testes de repositório. Uma string aceita por um navegador Date não é garantida em todos os idiomas, e um formulário especializado rejeitado não refuta sua posição em outro lugar.

A precisão fixa de milissegundos da saída é uma escolha de formatação e não uma evidência de que a fonte mediu milissegundos. A data pode ter recebido um valor de segundo inteiro e ainda imprime `.000`.

ToolAcre emite um formato em formato de ISO; ele não valida o padrão ISO 8601 completo

A apostila caracterizava RFC 3339, seu ano e regras de compensação obrigatórias. Não existe texto RFC ou analisador dedicado no conjunto de origem, portanto, esses detalhes não são declarados. O contrato de autoria exige deixar de fora a precisão não comprovada, em vez de citar um título de memória.

Se seu API significa RFC 3339, nomeie-o no esquema e teste em uma implementação baseada na especificação real. ToolAcre pode conectar uma época conhecida à sua saída UTC ISO para comparação, mas não pode certificar que a entrada arbitrária satisfaça esse perfil.

Esta é uma salvaguarda editorial e de engenharia: os perfis de padrões são contratos precisos e parafraseá-los sem o texto corre o risco de alterar os requisitos da documentação.

Os requisitos de RFC 3339 precisam de uma fonte de padrões externa não presente neste repositório

As reivindicações sobre separadores alternativos, designadores minúsculos e `−00:00` dependem da linguagem dos padrões exatos. Eles são omitidos aqui. O próprio detector de zona do conversor reconhece Z à direita ou `±HH:MM` numérico e sinaliza datas e horas sem zona como locais; esse é o limite que podemos verificar.

Crie validação API a partir de exemplos explícitos aceitos e casos de rejeição. Não inferir permissão do analisador de conveniência JavaScript Date. Um navegador permissivo pode normalizar entradas que um servidor estrito rejeita corretamente, ocultando defeitos de interoperabilidade durante testes manuais.

Um analisador dedicado com reconhecimento de padrões deve retornar motivos de erros estruturados. Permitir que Date normalize a entrada ampla pode transformar um bug de validação API em uma discrepância posterior entre plataformas.

Regras específicas de separador e deslocamento desconhecido são omitidas sem o texto dos padrões

Os valores de época tornam a aritmética e a ordenação compactas quando a unidade e a origem são fixas. As datas e horas textuais tornam uma leitura UTC ou offset visível para as pessoas e preservam esse designador em trânsito. Muitas APIs escolhem uma string canônica para evitar JavaScript ambiguidade de número inteiro ou unidade.

Se um API carregar ambos, defina qual campo é oficial e teste a concordância. Uma string formatada obsoleta ao lado de uma época nova é pior do que qualquer uma delas sozinha. ToolAcre pode comparar o par convertendo o número inteiro e verificando o valor ISO gerado, mas a aplicação de consistência pertence ao produtor.

Exemplo resolvido: um instante, quatro representações - segundos de época, milissegundos de época, uma string RFC 3339 em UTC e uma com deslocamento local

Use `2025-02-03T10:22:00.000Z` instantâneo. Seus formatos de época são 1,738,578,120 segundos e 1,738,578,120,000 milissegundos. Uma leitura de deslocamento explícito é `2025-02-03T12:22:00+02:00`; analisá-lo em ToolAcre retorna a mesma época e linha canônica UTC ISO.

Estas são quatro representações verificáveis ​​pelo repositório: segundos, milissegundos, saída toISOString e uma string de deslocamento numérico analisada por data. O exemplo não afirma que todo analisador externo aceita a mesma precisão fracionária ou sintaxe de deslocamento. Execute a validação do próprio API antes do envio.

Subtrair o deslocamento +02:00 do relógio escrito resulta em 10:22 UTC. Essa simples igualdade é suficiente para testar esta entrada específica sem generalizar uma gramática padrão completa.

Exemplo resolvido: um instante nas quatro formas que este repositório pode verificar

HTTP cabeçalhos e datas de e-mail usam contratos textuais não implementados aqui. ToolAcre não formata esses protocolos, nem promete que sua saída ISO possa ser substituída. O instante de um carimbo de data/hora pode ser o mesmo, embora a representação da ligação necessária seja diferente.

Mantenha a serialização do protocolo em adaptadores dedicados com equipamentos copiados de especificações oficiais. Use a conversão de época para verificar o instante subjacente e, em seguida, teste a gramática separadamente. Isso evita que um valor correto do calendário seja aprovado na revisão em um envelope sintaticamente inválido.

O adaptador dedicado também deve preservar se o deslocamento ausente ou desconhecido carrega significado de domínio. Achatar cada data textual em uma suposição local pode destruir essa informação.

Outros protocolos textuais permanecem fora do conversor

Especifique o formato restrito que seu API aceita em vez de depender de um rótulo amplo. Para esta ferramenta, a saída reproduzível mais segura é a string UTC ISO retornada por `toISOString()`, e a entrada numérica mais segura inclui um contrato explícito de segundos ou milissegundos.

ToolAcre preenche essas suposições de formulários e relatórios. Ele não julga todos os casos extremos ISO 8601 ou RFC 3339. A propriedade clara da gramática, da unidade e do designador de zona é o que torna os carimbos de data/hora portáteis – sem anexar um nome padrão familiar a um campo subespecificado.

Um contrato preciso permite que os clientes falhem antecipadamente com mensagens úteis. Um rótulo amplo empurra a discordância para o tempo de execução, onde dois analisadores corretos podem escolher subconjuntos diferentes.