Só porque a data está escrita no esquema JSON, isso não significa que o validador deva verificar a data.
O esquema diz `format: date`, mas a data incorreta passa na verificação. Isso pode não significar necessariamente que haja um bug na biblioteca. A forma como `format` é tratado depende da configuração do validador. Quando você obtiver uma "verificação bem-sucedida", primeiro pergunte se ele verificou o tipo, a estrutura ou também a semântica da data.
format: date é escrito no esquema JSON, mas uma data inexistente passa na verificação. Geralmente isso não é um bug na biblioteca. A forma como format é tratado depende da configuração do validador. Ao encontrar um resultado de "verificação bem-sucedida", você deve primeiro confirmar se ele verifica o tipo, a estrutura ou também a semântica da data.
Este artigo é adequado para desenvolvedores e revisores que precisam realizar verificação estruturada de dados de documentos e se preocupar com a precisão dos campos de data. Depois de ler isto, você será capaz de determinar o que significa uma verificação de aprovação e usar testes de contra-exemplo para corrigir as regras de data.
Este artigo utiliza amostras sintéticas para demonstrar o método de processamento. O código foi verificado com exemplos em um ambiente isolado e não é garantia de todos os arquivos reais ou desempenho do produto. Antes de processar documentos importantes, guarde os originais e revise-os de acordo com os limites e itens de aceitação do texto.
O que exatamente a verificação de data do esquema JSON verifica? Conclusão de uma frase
Primeiro confirme se a verificação format está habilitada no validador e, em seguida, confirme se as regras semânticas da data (se ela realmente existe e como interpretá-la) são responsáveis.
| sua situação | Práticas recomendadas | razão |
|---|---|---|
Verifique apenas format: date com validador padrão | Primeiro confirme se o FormatChecker está explicitamente habilitado | A forma como format é tratado depende da configuração do validador |
Precisa identificar datas como 2026-02-30 | Coloque-o no conjunto de testes como um contra-exemplo | A string se parece com uma data, o que não significa que exista no calendário. |
| A ordem do dia e mês da data de origem é desconhecida. | Marque ambigüidade, sem adivinhação automática | A aprovação na verificação date só pode mostrar que o valor convertido é válido |
| Campos com hora e fuso horário | Use protocolos de tempo independentes | Os primeiros dez caracteres não devem ser interceptados e processados casualmente |
| Usado para verificação de data de tradução | Salve raw_text e valores normalizados | Os revisores precisam ver tanto o conteúdo original quanto a explicação sistemática |
Duas verificações aparentemente idênticas
2026-02-30 é uma string e parece uma data, mas não há 30 dias em fevereiro. Somente a verificação de formas regulares deixará de lado esse tipo de problema. A seguir, usamos jsonschema do Python para comparar os resultados do validador padrão e ativar explicitamente FormatChecker.
Teste a configuração com uma data impossível
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)
O exemplo sintético verifica apenas date. Outros formatos podem ter dependências opcionais ou diferenças de implementação e devem ser testados caso a caso em um ambiente bloqueado. Nomes de formatos desconhecidos não podem significar que algum tipo de verificação foi implementado, e erros ortográficos podem dar uma sensação de segurança sem sentido.
O formato da data não é uma regra de interpretação de data
03/04/2026 na fonte pode significar 4 de março ou 3 de abril. A região de origem, especificação de campo ou protocolo explícito é necessária antes de convertê-la para o formato ISO. A aprovação na verificação date só pode provar que o valor convertido é válido, mas não pode provar que você selecionou o mês correto.
| Informação de origem | o que fazer | O que não fazer |
|---|---|---|
| Data do calendário que não existe | Relate um erro e revise a fonte | Rolar automaticamente para o próximo mês |
| Ordem desconhecida do sol e da lua | Ambiguidade de tags | Adivinhe com base no idioma do servidor |
| Com hora e fuso horário | Use protocolos de tempo independentes | Intercepte aleatoriamente os primeiros dez caracteres |
| O campo está vazio | Trate de acordo com as regras que faltam | Complemente a data de hoje |
Incorporar configuração em testes de regressão
Coloque pelo menos três tipos de valores no conjunto de teste: um dia bissexto legal, um dia bissexto ilegal e um valor malformado. Executar esses contra-exemplos durante a implantação é mais eficiente do que apenas verificar se o arquivo Schema existe. Se o serviço for implementado em vários idiomas, o mesmo conjunto de testes deverá ser verificado separadamente e não assumir que o comportamento padrão dos dois validadores é o mesmo.
A revisão da tradução mantém a data original
Ao usar os resultados da extração de data para verificação de tradução OmniDoc, é recomendado salvar raw_text e valores normalizados. O revisor precisa ver"qual é o conteúdo original"e"como o sistema o interpreta"para determinar se a diferença está na tradução, extração ou conversão de formato.
Referências: String e formato do esquema JSON.
📊 Comparação principal
| Item comparativo | Validador padrão | Habilite explicitamente o FormatChecker |
|---|---|---|
| Verifique o escopo | Tipos e estruturas | Verificação adicional do formato da declaraçãoformat |
Conclusão sobre 2026-02-30 | Não presuma rejeição | Precisa ser confirmado com contra-exemplos |
| significado ao passar | Isso não significa que a semântica da data esteja correta | Ainda preciso verificar a explicação da data no negócio |
🎯 Qual método é adequado para você?
Se você só precisa ter certeza de que o campo é uma string ou está estruturado corretamente
O validador padrão geralmente é suficiente, mas esteja ciente de que ele não verifica necessariamente a semântica da data.
Se você precisar confirmar se a data realmente existe
Habilite explicitamente o FormatChecker e verifique com contra-exemplos como 2026-02-30.
Se você quiser verificar a data no arquivo de origem
Primeiro confirme as regras de origem da sequência de dias e meses e, em seguida, salve o texto original e os valores normalizados.
Se o seu serviço for implantado em vários idiomas
O mesmo conjunto de testes é executado em cada implementação.
❓ Perguntas frequentes (FAQ)
1. O esquema é escrito como format: date, por que datas ruins ainda podem passar?
A forma como o format é tratado depende da configuração do validador e a semântica da data não é necessariamente verificada por padrão.
2. Por que 2026-02-30 é um valor de teste útil?
Parece uma data, mas fevereiro não tem trigésimo dia. Apenas verificar a aparência deixará escapar esse tipo de problema.
3. O que acontece se um nome de formato desconhecido for usado?
Não deve ser tratado como se tivesse sido verificado, e erros ortográficos podem dar uma falsa sensação de segurança.
4. Como 03/04/2026 deve ser convertido?
É necessário região de origem, descrição do campo ou protocolo explícito. Caso contrário, seria impossível dizer se representa 4 de março ou 3 de abril.
📝 Resumo
Passar na verificação significa apenas que os dados atendem às regras declaradas, mas não significa que o significado de cada data esteja correto. Primeiro confirme o escopo de verificação do validador e, em seguida, use contra-exemplos e regras de origem para fixar o processamento da data, para que os resultados sejam mais confiáveis.
Experimente agora: carregue o documento para iniciar a tradução, mantendo o layout original


