Het feit dat de datum in JSON Schema is geschreven, betekent niet dat de validator de datum moet controleren.

format: date is geschreven in het JSON-schema, maar een niet-bestaande datum komt door de verificatie. Dit is meestal geen bug in de bibliotheek. Hoe format wordt afgehandeld, hangt af van de validatorconfiguratie. Wanneer u het resultaat 'verificatie succesvol' tegenkomt, moet u eerst bevestigen of het type, de structuur of ook de datumsemantiek wordt gecontroleerd.

Dit artikel is geschikt voor ontwikkelaars en reviewers die gestructureerde verificatie van documentgegevens moeten uitvoeren en zich zorgen maken over de nauwkeurigheid van datumvelden. Nadat u dit heeft gelezen, kunt u bepalen wat een geslaagde verificatie betekent en kunt u tegenvoorbeeldtests gebruiken om de datumregels vast te stellen.

In dit artikel worden kunststofmonsters gebruikt om de verwerkingsmethode aan te tonen. De code is gecontroleerd met voorbeelden in een geïsoleerde omgeving en is geen garantie voor alle echte bestanden of productprestaties. Voordat u belangrijke documenten verwerkt, dient u de originelen te bewaren en deze te controleren op basis van de grenzen en acceptatie-items in de tekst.

Wat controleert de datumverificatie van JSON Schema precies? Conclusie in één zin

Bevestig eerst of de format-controle is ingeschakeld in de validator en bevestig vervolgens of de semantische regels van de datum (of deze daadwerkelijk bestaat en hoe deze moeten worden geïnterpreteerd) anderszins verantwoordelijk zijn.

Twee schijnbaar identieke cheques

2026-02-30 is een tekenreeks en ziet eruit als een datum, maar er is geen 30e dag in februari. Alleen het controleren van reguliere vormen zal dit soort problemen over het hoofd zien. Het volgende gebruikt jsonschema van Python om de resultaten van de standaardvalidator te vergelijken en FormatChecker expliciet in te schakelen.

Test de configuratie met een onmogelijke datum

from jsonschema import Draft202012Validator, FormatChecker

schema = {"type": "string", "format": "date"}
structural = Draft202012Validator(schema)
strict = Draft202012Validator(schema, format_checker=FormatChecker())

def valid(v, value):
    return not list(v.iter_errors(value))

assert valid(structural, "2026-02-30")
assert not valid(strict, "2026-02-30")
assert valid(strict, "2024-02-29")
assert not valid(strict, "2025-02-29")
assert not valid(strict, "26/09/2026")
assert not valid(strict, 20260926)

Het synthetische voorbeeld verifieert alleen date. Andere formaten kunnen optionele afhankelijkheden of implementatieverschillen hebben en moeten van geval tot geval worden getest in een afgesloten omgeving. Onbekende formaatnamen kunnen niet worden opgevat als een teken dat er een of andere controle is uitgevoerd, en spelfouten kunnen u een gevoel van betekenisloze veiligheid geven.

Het datumformaat is geen datuminterpretatieregel

03/04/2026 in de bron kan 4 maart betekenen, of 3 april. De bronregio, veldspecificatie of expliciet protocol zijn vereist voordat deze naar ISO-vorm worden geconverteerd. Het slagen voor de date-verificatie kan alleen bewijzen dat de omgerekende waarde geldig is, maar kan niet bewijzen dat u de juiste maand heeft geselecteerd.

Configuratie opnemen in regressietesten

De testset bevat minstens drie soorten waarden: één geldige schrikkeldag, één illegale schrikkeldag en één onjuiste waarde. Het uitvoeren van deze tegenvoorbeelden tijdens de deployment is effectiever dan simpelweg controleren of het schemabestand bestaat. Als de service over verschillende talen wordt geïmplementeerd, moet dezelfde testset afzonderlijk worden gevalideerd en mag het standaardgedrag van twee validators niet als identiek worden aangenomen.

Vertaalrecensie behoudt de oorspronkelijke datum

Bij het gebruik van het datumextractieresultaat voor OmniDoc-vertalingsverificatie wordt aanbevolen zowel raw_text- als genormaliseerde waarden op te slaan. Beoordelaars moeten zien "wat de oorspronkelijke inhoud is" en "hoe het systeem deze interpreteert" om verschillen in vertaling, extractie of formaatconversie te identificeren.

Bronnen: JSON-schematekenreeks en -indeling.

📊 Kernvergelijking

🎯 Welke methode past bij jou?

Als je alleen hoeft te bevestigen dat het veld een string is of de juiste structuur heeft

De standaard validator is meestal voldoende, maar wees je ervan bewust dat deze niet per se de datumsemantiek controleert.

Als je wilt bevestigen dat de datum echt bestaat

Schakel expliciet FormatChecker in en verifieer met tegenvoorbeelden zoals 2026-02-30.

Als je de datum in het bronbestand wilt verifiëren

Bevestig eerst de bronregels voor de dag-maand volgorde, sla vervolgens de originele tekst en genormaliseerde waarden op.

Als je dienst over verschillende talen heen wordt ingezet

Voer dezelfde testset apart uit in elke implementatie.

❓ Veelgestelde Vragen (FAQ)

1. Het schema schreef format: date, dus waarom kunnen slechte data nog steeds doorgaan?

De afhandeling van format hangt af van de validatorconfiguratie; standaard kan datumsemantiek niet worden gecontroleerd.

2. Waarom is 2026-02-30 een nuttige testwaarde?

Het lijkt een datum, maar februari heeft geen dertigste dag. Alleen op het uiterlijk focussen zal dit soort problemen missen.

3. Wat gebeurt er als je een naam van een onbekend formaat gebruikt?

Het moet niet als gecontroleerd worden beschouwd; spelfouten kunnen je een vals gevoel van veiligheid geven.

4. Hoe moet 03/04/2026 worden omgezet?

Bronregio, veldbeschrijving of duidelijke overeenkomst zijn vereist. Anders is het onmogelijk te zeggen of het 4 maart of 3 april vertegenwoordigt.

📝 Samenvatting

Het slagen voor een checkcheck betekent alleen dat de data voldoet aan de opgegeven regels en niet dat elke datum correct is. Bevestig eerst de inspectiescope van de validator, en pas vervolgens de datumverwerking aan met tegenvoorbeelden en bronregels voor betrouwbaardere resultaten.

Ervaar nu: upload je document om te beginnen met vertalen, waarbij je de originele opmaak behoudt