ISO 8601 Tidsstempel Validator og Formatter

Hvad Validator kontrol

Denne validator er designet til en praktisk udvikler workflow: indsætte et tidsstempel eller dato streng, kontrollere, om det matcher den forventede ISO 8601 form, og fange indlysende formateringsproblemer, før værdien sendes til en API, gemt i JSON, eller kopieret i en konfigurationsfil. Det kontrollerer, om værdien ligner en gyldig ISO- stil dato eller tidsstempel, og om browseren kan fortolke det til en reel dato i stedet for en umulig.

Hvad denne validator ikke tjekker

En streng kan være strukturelt gyldig her og stadig være forkert til din ansøgning. Denne side kender ikke dine forretningsmæssige regler, begivenhed bestilling, API schema krav, eller om en downstream service insisterer på en tidszone offset, en UTC Z suffiks, brøkdele sekunder, eller en data- kun format. Det hjælper dig fange format fejl, men det erstatter ikke kontrakten defineret af det system, der i sidste ende vil forbruge tidsstempel.

Fælles grunde en ISO 8601 Tidsstempel mislykkes

De mest almindelige fejl er simple: mangler T separator, ved hjælp af et rum, hvor en streng tidsstempel forventer T, skrive en umulig måned eller dag, udelade en nødvendig tidszone offset, tilføje ekstra efterfølgende tekst, eller kopiere en værdi med skjult whitespace fra et regneark eller log viewer. Et tidsstempel kan også mislykkes, fordi det ser tæt på ISO 8601, men ikke indeholder de nøjagtige brikker dit mål system forventer.

Accepterede eksempler og afviste eksempler

Gode eksempler omfatter en fuld UTC tidsstempel såsom 2026- 03- 05T17: 46: 39Z og en date- kun værdi såsom 2026- 03- 05, når en dato er alt hvad du behøver. Afviste indgange omfatter ofte værdier som 2026 / 03 / 05, tidsstempler med en plads, men ingen tidszone, eller strenge med delvist manglende tidsfelter. Sammenligning af et forbipasserende og svigtende eksempel side om side er ofte den hurtigste måde at se, om problemet er punktuering, tidszone notation, eller en umulig kalenderværdi.

UTC, offset og betydningen af Z

Z suffikset betyder UTC. En eksplicit forskydning såsom + 00: 00 repræsenterer også UTC, mens værdier som -05: 00 eller + 02: 00 repræsenterer den samme slags tidsstempel med en anden lokal forskydning. To strenge kan repræsentere det samme øjeblik, mens du ser anderledes på skærmen, fordi en er skrevet i UTC og en anden er skrevet med en regional forskydning. Det er en af grundene til tidsstempel debugging ofte kræver både validering og fortolkning, ikke bare mønster matchning.

Date- Kun vs Date- Time Input

En data- kun værdi som 2026- 03- 05 kan være gyldig ISO 8601, men det ikke bære en time- of- dag eller tidszone. Det kan være acceptabelt for forfaldsdatoer, rapporteringsintervaller og kalenderfelter, men ikke for hændelsestidsstempler, revisionsoptegnelser eller API-nyttelaster, der har brug for et nøjagtigt øjeblik. Brug denne sondring til at afgøre, om en værdi er blot gyldig eller faktisk egnet til det system, du tester.

Hvordan til at fastsætte en Ugyldig Tidsstempel

Start med at trimme værdien og kontrollere separatorerne. Bekræft derefter, om målsystemet kun forventer en dato, et UTC-tidsstempel med Z eller et tidsstempel med en eksplicit numerisk forskydning. Hvis værdien kom fra et regneark, log eksport eller kopieret UI felt, fjerne ekstra mellemrum og bekræfte, at måneden, dag, og tid stykker er færdige. Små punktueringsproblemer er ofte den egentlige årsag til et mislykket valideringsresultat.

Privatliv og lokal validering

Validering kører i din browser, så du kan inspicere tidsstempler fra logfiler, webkroge, tidsplaner og interne systemer uden at sende dem til en tredjeparts tidsstempler. Det er nyttigt, når selve værdien er følsom, bundet til en hændelse, eller en del af en nyttelast, du hellere vil holde i en lokal debugging session.