Perché TOML ha un tipo data-ora nativo e JSON no (RFC 3339)

La data che è diventata una stringa: una configurazione TOML con una data di rilascio, convertita in JSON e ridotta in testo

Una data locale TOML come `1979-05-27` diventa la stringa JSON `"1979-05-27"`. I caratteri del calendario sopravvivono, ma il tipo TOML nativo no. La conversione di JSON indietro scrive una stringa tra virgolette, non un token di data e ToolAcre avvisa alla prima conversione.

Questo è un limite inevitabile nel valore semplice JSON scelto. Chiamare il viaggio di andata e ritorno senza perdite confonderebbe il testo conservato con il tipo conservato. L'avviso nomina sia il percorso che il tipo temporale in modo che i revisori possano decidere se una stringa è accettabile a valle.

Perché JSON non ha un tipo di data: il minimalismo di Crockford, la convenzione sulle stringhe ISO 8601 e la convenzione dei millisecondi dall'epoca che competono per colmare il divario

JSON l'analisi qui produce null, booleani, numeri, stringhe, matrici e oggetti; non produce oggetti Date. Il repository dimostra questo fatto di implementazione ma non fornisce spiegazioni storiche per il minimalismo di JSON o per le convenzioni di settore concorrenti.

Le applicazioni possono adottare stringhe simili a ISO o numeri di epoca previo accordo, ma si tratta di convenzioni stratificate su JSON. I convertitori di sintassi non ne deducono uno da testo arbitrario e non convertono i valori temporali TOML nell'aritmetica delle epoche.

JSON non ha un tipo di data nativo in questo convertitore; la logica dell’origine è al di fuori delle prove del deposito

TOML espone quattro tipi: data-ora di offset con Z o offset numerico, data-ora locale senza zona, data locale e ora locale. smol-toml li rappresenta come oggetti simili a date che trasportano metadati gentili; ToolAcre identifica ciascuno prima di normalizzarlo.

La distinzione evita un grave errore. L'ora locale non viene assegnata automaticamente a UTC e la data e l'ora locale non vengono spostate tra le zone. Il suo offset assente rimane assente nella stringa JSON.

RFC 3339 come base: il profilo di ISO 8601 che TOML prende in prestito, inclusa la franchigia per il separatore di spazi

Il normalizzatore chiama il formattatore ISO del valore del parser e rimuove solo una frazione sintetica `.000`. Conserva i secondi frazionari significativi e la forma locale orientata alla fonte rispetto a quella offset. Il codice lo descrive come testo RFC 3339, ma l'articolo non inventa clausole specifiche come i margini di separatore oltre l'output testato.

Un esempio di offset rimane testo data-ora anziché essere convertito in un valore Z universale da questo livello. Ciò evita di modificare la rappresentazione scritta e mantiene l'interpretazione temporale per l'applicazione che la possiede.

ToolAcre preserva il testo temporale orientato all'origine senza dichiarare i dettagli completi di conformità RFC 3339

Ogni valore temporale diventa una stringa e gli avvisi indicano che JSON, YAML e XML non hanno un tipo di data in questo modello di conversione. Gli offset non vengono deliberatamente eliminati e i valori locali non ne acquisiscono uno. Le informazioni perse appartengono alla categoria di tipo TOML stessa.

Nella conversione inversa, la stringa viene quotata perché lo scrittore non ha alcun indicatore che gli indichi di ripristinare una data/ora. La nuova analisi di stringhe arbitrarie che sembrano date come date digiterebbe in modo errato identificatori o etichette ordinarie e inventerebbe una convenzione non condivisa da JSON.

Il convertitore preserva l'ortografia locale rispetto a quella offset, quindi perde il tipo TOML nativo

Utilizza `odt = 1979-05-27T07:32:00Z`, `ldt = 1979-05-27T07:32:00`, `ld = 1979-05-27` e `lt = 07:32:00`. JSON contiene quattro stringhe con queste ortografie. L'avviso elenca i percorsi di data-ora, data-ora locale, data locale e ora locale.

Converti nuovamente JSON in TOML. Ogni valore è citato. Un `00.500Z` frazionario rimane frazionario, mentre un valore di un secondo intero non guadagna `.000`. Questo è il comportamento effettivamente supportato e dimostra chiaramente il testo conservato rispetto al tipo perso.

Esempio realizzato: tutti e quattro i tipi temporali TOML diventano stringhe e restituiscono virgolette

La ricerca delle regole del fuso orario, le transizioni all'ora legale e la conversione dell'epoca non fanno parte di questo percorso. Una data-ora locale senza zona non può diventare un istante unico senza ulteriori informazioni. Il convertitore di timestamp Unix indirizza istanti noti con un contratto diverso.

Non inserire ogni stringa risultante nella data JavaScript e assumere un significato equivalente. La data locale, l'ora locale e la data/ora senza zona richiedono il contesto dell'applicazione. Conservare l'avviso e la semantica del campo durante la migrazione.

Conclusione: TOML sa cos'è una data, JSON sa solo cos'è una stringa e come il pannello dei convertitori di sintassi mostra questa differenza nel tuo browser

TOML conosce quattro categorie temporali; JSON riceve qui solo stringhe. ToolAcre preserva attentamente l'ortografia e rifiuta di inventare una zona, ma il tipo nativo è scomparso e non può essere ricostruito automaticamente al ritorno.

Esamina ogni percorso avvisato e definisci una convenzione applicativa quando la semantica temporale deve sopravvivere. Se non esiste una convenzione di questo tipo, mantieni TOML come fonte autorevole anziché considerare equivalente un viaggio di andata e ritorno citato.

Una convenzione sonora nomina anche quali stringhe possono essere analizzate nuovamente e in quale contesto. Una data-ora spostata può identificare un istante, mentre una data-ora locale, una data o un'ora non possono farlo senza regole aggiuntive. Memorizza il tipo originale accanto alla stringa normalizzata quando una fase successiva deve ricostruire TOML o pianificare il lavoro. Altrimenti accetta che JSON contenga testo visualizzato ed evita di promuoverlo silenziosamente a un timestamp universale.