Por que TOML tem um tipo de data e hora nativo e JSON não (RFC 3339)

A data que se tornou uma string — uma configuração TOML com data de lançamento, convertida em JSON e reduzida para texto

Uma data local TOML como `1979-05-27` torna-se a string JSON `"1979-05-27"`. Os caracteres do calendário sobrevivem, mas o tipo nativo TOML não. A conversão de JSON de volta grava uma string entre aspas, não um token de data, e ToolAcre avisa na primeira conversão.

Este é um limite inevitável no valor JSON simples escolhido. Chamar a viagem de ida e volta sem perdas confundiria texto preservado com tipo preservado. O aviso nomeia o caminho e o tipo temporal para que os revisores possam decidir se uma string é aceitável no downstream.

Por que JSON não tem tipo de data - o minimalismo de Crockford, a convenção de string ISO 8601 e a convenção de milissegundos desde a época que competem para preencher a lacuna

JSON a análise aqui produz nulos, booleanos, números, strings, arrays e objetos; não produz objetos Date. O repositório prova esse fato de implementação, mas não fornece explicações históricas para o minimalismo de JSON ou convenções concorrentes da indústria.

Os aplicativos podem adotar strings semelhantes a ISO ou números de época por acordo, mas essas são convenções colocadas em camadas em JSON. Os conversores de sintaxe não inferem um texto arbitrário e não convertem valores temporais TOML em aritmética de época.

JSON não possui tipo de data nativo neste conversor; a justificativa de origem está fora da evidência do repositório

TOML expõe quatro tipos: deslocamento de data e hora com deslocamento Z ou numérico, data e hora local sem fuso, data local e hora local. smol-toml os representa como objetos semelhantes a datas que carregam metadados de tipo; ToolAcre identifica cada um antes de normalizá-lo.

A distinção evita um erro grave. Uma hora local não é atribuída silenciosamente UTC e uma data e hora local não é movida entre zonas. Seu deslocamento ausente permanece ausente na string JSON.

RFC 3339 como base — o perfil de ISO 8601 que TOML toma emprestado, incluindo a permissão do separador de espaço

O normalizador chama o formatador ISO do valor do analisador e remove apenas uma fração sintética `.000`. Ele preserva segundos fracionários significativos e formato local versus deslocamento orientado à fonte. O código descreve isso como texto RFC 3339, mas o artigo não inventa cláusulas de especificação, como permissões de separador além da saída testada.

Um exemplo de deslocamento permanece como texto de data e hora em vez de ser convertido em um valor Z universal por esta camada. Isso evita alterar a representação escrita e mantém a interpretação temporal para a aplicação que a possui.

ToolAcre preserva texto temporal orientado à origem sem declarar detalhes completos de conformidade de RFC 3339

Cada valor temporal se torna uma string e os avisos dizem que JSON, YAML e XML não possuem tipo de data neste modelo de conversão. As compensações não são eliminadas deliberadamente e os valores locais não as adquirem. A informação perdida é da própria categoria do tipo TOML.

Na conversão reversa, a string é colocada entre aspas porque o gravador não possui nenhum marcador informando para restaurar uma data e hora. A nova análise de strings arbitrárias com aparência de data como datas digitaria incorretamente identificadores ou rótulos comuns e inventaria uma convenção não compartilhada por JSON.

O conversor preserva a ortografia local versus offset e, em seguida, perde o tipo nativo TOML

Use `odt = 1979-05-27T07:32:00Z`, `ldt = 1979-05-27T07:32:00`, `ld = 1979-05-27` e `lt = 07:32:00`. JSON contém quatro strings com essas grafias. O aviso lista os caminhos de data e hora de deslocamento, data e hora local, data local e hora local.

Converta JSON de volta em TOML. Cada valor é cotado. Um `00.500Z` fracionário permanece fracionário, enquanto um valor de segundo inteiro não ganha `.000`. Este é o comportamento real suportado e demonstra claramente o texto preservado versus o tipo perdido.

Exemplo resolvido: todos os quatro tipos temporais TOML tornam-se strings e retornam entre aspas

A pesquisa de regras de fuso horário, as transições para o horário de verão e a conversão de época não fazem parte desta rota. Uma data e hora local sem zona não pode se tornar um instante único sem mais informações. O conversor de carimbo de data/hora Unix endereça instantes conhecidos sob um contrato diferente.

Não alimente cada string resultante com JavaScript Date e assuma um significado equivalente. A data local, a hora local e a data e hora sem zona requerem contexto de aplicação. Preserve o aviso e a semântica do campo por meio da migração.

Conclusão: TOML sabe o que é uma data, JSON só sabe o que é uma string - e como o painel de conversores de sintaxe mostra essa diferença em seu navegador

TOML conhece quatro categorias temporais; JSON recebe apenas strings aqui. ToolAcre preserva a ortografia cuidadosamente e se recusa a inventar uma zona, mas o tipo nativo desapareceu e não pode ser reconstruído automaticamente no retorno.

Revise cada caminho avisado e defina uma convenção de aplicação quando a semântica temporal precisar sobreviver. Se tal convenção não existir, mantenha TOML como fonte oficial em vez de tratar uma viagem de ida e volta citada como equivalente.

Uma convenção de som também nomeia quais strings podem ser analisadas novamente e em que contexto. Um deslocamento de data e hora pode identificar um instante, enquanto uma data e hora local, data ou hora não pode fazê-lo sem regras adicionais. Armazene o tipo original ao lado da string normalizada quando um estágio posterior precisar reconstruir TOML ou agendar trabalho. Caso contrário, aceite que JSON está carregando texto de exibição e evite promovê-lo silenciosamente para um carimbo de data/hora universal.