Convalidatore e formattatore del timestamp ISO 8601

Che cosa questo convalidatore controlla

Questo validatore è progettato per un flusso di lavoro pratico dello sviluppatore: incollare un timestamp o una stringa di data, verificare se corrisponde alla forma ISO 8601 prevista e catturare problemi di formattazione evidenti prima che il valore venga inviato a un API, memorizzato in JSON, o copiato in un file di configurazione. Controlla se il valore sembra una data o un timestamp valido in stile ISO e se il browser può analizzarlo in una data reale invece di una data impossibile.

Ciò che questo validatore non controlla

Una stringa può essere strutturalmente valida qui e ancora essere sbagliata per la vostra applicazione. Questa pagina non conosce le regole del tuo business, l'ordine degli eventi, i requisiti dello schema API, o se un servizio a valle insiste su un offset del fuso orario, un suffisso UTC Z, secondi frazionari o un formato di sola data. Aiuta a catturare errori di formato, ma non sostituisce il contratto definito dal sistema che alla fine consumerà il timestamp.

Motivi comuni un ISO 8601 Timestamp Fails

I guasti più comuni sono semplici: manca il separatore T, utilizzando uno spazio in cui un timestamp rigoroso si aspetta T, digitando un mese o un giorno impossibile, omettendo un offset temporale richiesto, aggiungendo un testo extra trailing, o copiando un valore con spazio bianco nascosto da un foglio di calcolo o un visualizzatore di log. Un timestamp può anche fallire perché sembra vicino a ISO 8601 ma non include i pezzi esatti che il sistema di destinazione si aspetta.

Esempi accettati e Esempi respinti

Buoni esempi includono un timestamp UTC completo come 2026-03-05T17:46:39Z e un valore di sola data come 2026-03-05 quando una data è tutto il necessario. Gli ingressi respinti includono spesso valori come 2026/03/05, timestamp con uno spazio ma senza fuso orario, o stringhe con campi di tempo parzialmente mancanti. Confrontare un esempio di passaggio e mancante fianco a fianco è spesso il modo più veloce per vedere se il problema è punteggiatura, notazione di fuso orario, o un valore del calendario impossibile.

UTC, Offsets, e il significato di Z

Il suffisso Z significa UTC. Un offset esplicito come +00:00 rappresenta anche UTC, mentre valori come -05:00 o +02:00 rappresentano lo stesso tipo di timestamp con un diverso offset locale. Due stringhe possono rappresentare lo stesso istante mentre si guarda diverso sullo schermo perché uno è scritto in UTC e un altro è scritto con un offset regionale. Questo è un motivo per cui il debugging timestamp richiede spesso sia la validazione che l'interpretazione, non solo la corrispondenza del modello.

Date-Only vs Date-Time Inputs

Un valore di sola data come 2026-03-05 può essere valido ISO 8601, ma non porta un fuso orario o un fuso orario. Ciò può essere accettabile per date, intervalli di report e campi di calendario, ma non per timestamp eventi, record di audit, o API payload che hanno bisogno di un istante esatto. Utilizzare questa distinzione per decidere se un valore è semplicemente valido o effettivamente adatto per il sistema che si sta testando.

Come risolvere un timestamp non valido

Avviare tagliando il valore e controllando i separatori. Quindi confermare se il sistema di destinazione si aspetta solo una data, un timestamp UTC con Z, o un timestamp con un offset numerico esplicito. Se il valore proveniva da un foglio di calcolo, dall'esportazione di log o dal campo UI copiato, rimuovere gli spazi extra e confermare che il mese, il giorno e i pezzi di tempo sono completi. I piccoli problemi di punteggiatura sono spesso la vera causa di un risultato di validazione fallito.

Privacy e convalida locale

La validazione viene eseguita nel browser in modo da poter ispezionare timestamp da registri, webhooks, orari e sistemi interni senza inviarli a un timestamp di terze parti checker. Questo è utile quando il valore stesso è sensibile, legato ad un incidente, o parte di un payload si preferisce tenere in una sessione di debug locale.