Hanya karena tanggal ditulis dalam Skema JSON, bukan berarti validator harus memeriksa tanggalnya.
Skema mengatakan `format: date`, tetapi tanggal buruk lolos verifikasi. Ini belum tentu berarti ada bug di perpustakaan. Cara penanganan `format` bergantung pada konfigurasi validator. Ketika Anda mendapatkan "verifikasi berhasil", tanyakan terlebih dahulu apakah ia memeriksa jenis, struktur, atau juga memeriksa semantik tanggal.
format: date ditulis dalam Skema JSON, tetapi tanggal yang tidak ada lolos verifikasi. Ini biasanya bukan bug di perpustakaan. Cara penanganan format bergantung pada konfigurasi validator. Ketika Anda menemukan hasil "verifikasi berhasil", Anda harus mengonfirmasi terlebih dahulu apakah ia memeriksa jenis, struktur, atau juga memeriksa semantik tanggal.
Artikel ini cocok untuk pengembang dan peninjau yang perlu melakukan verifikasi terstruktur terhadap data dokumen dan memperhatikan keakuratan bidang tanggal. Setelah membaca ini, Anda akan dapat menentukan arti dari verifikasi yang lulus dan menggunakan pengujian contoh tandingan untuk memperbaiki aturan tanggal.
Artikel ini menggunakan sampel sintetis untuk mendemonstrasikan metode pemrosesan. Kode telah diperiksa dengan contoh di lingkungan yang terisolasi dan bukan merupakan jaminan atas semua file nyata atau kinerja produk. Sebelum memproses dokumen penting, harap simpan dokumen asli dan tinjau sesuai dengan batasan dan item penerimaan dalam teks.
Apa sebenarnya yang diperiksa verifikasi tanggal Skema JSON? Kesimpulan satu kalimat
Pertama-tama konfirmasikan apakah pemeriksaan format diaktifkan di validator, lalu konfirmasikan apakah aturan semantik tanggal (apakah tanggal tersebut benar-benar ada dan cara menafsirkannya) bertanggung jawab.
| situasi Anda | Praktik yang direkomendasikan | alasan |
|---|---|---|
Hanya periksa format: date dengan validator default | Pertama konfirmasikan apakah FormatChecker diaktifkan secara eksplisit | Cara penanganan format bergantung pada konfigurasi validator |
Perlu mengidentifikasi tanggal seperti 2026-02-30 | Masukkan ke dalam set pengujian sebagai contoh tandingan | Stringnya terlihat seperti tanggal, bukan berarti string tersebut ada di kalender. |
| Urutan hari dan bulan dari tanggal sumber tidak diketahui. | Tandai ambiguitas, tidak ada tebakan otomatis | Melewati verifikasi date hanya dapat menunjukkan bahwa nilai yang dikonversi valid |
| Bidang dengan waktu dan zona waktu | Gunakan protokol waktu independen | Sepuluh karakter pertama tidak boleh dicegat dan diproses begitu saja |
| Digunakan untuk verifikasi tanggal terjemahan | Simpan nilai raw_text dan nilai yang dinormalisasi | Reviewer perlu melihat konten asli dan penjelasan sistematisnya |
Dua cek yang tampak identik
2026-02-30 adalah string dan terlihat seperti tanggal, tetapi tidak ada hari ke 30 di bulan Februari. Hanya memeriksa bentuk biasa yang akan melewatkan masalah seperti ini. Berikut ini menggunakan jsonschema Python untuk membandingkan hasil validator default dan secara eksplisit mengaktifkan FormatChecker.
Uji konfigurasi dengan tanggal yang mustahil
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)
Contoh sintetik hanya memverifikasi date. Format lain mungkin memiliki ketergantungan opsional atau perbedaan implementasi dan harus diuji berdasarkan kasus per kasus di lingkungan yang terkunci. Nama format yang tidak dikenal tidak dapat diartikan bahwa semacam pemeriksaan telah diterapkan, dan kesalahan ejaan dapat memberi Anda rasa aman yang tidak berarti.
Format tanggal bukan merupakan aturan penafsiran tanggal
03/04/2026 dalam sumbernya mungkin berarti 4 Maret, atau bisa juga berarti 3 April. Wilayah sumber, spesifikasi bidang, atau protokol eksplisit diperlukan sebelum mengubahnya menjadi bentuk ISO. Lolos verifikasi date hanya dapat membuktikan bahwa nilai yang dikonversi valid, namun tidak dapat membuktikan bahwa Anda memilih bulan yang benar.
| Sumber informasi | apa yang harus dilakukan | Apa yang tidak boleh dilakukan |
|---|---|---|
| Tanggal kalender yang tidak ada | Laporkan kesalahan dan tinjau sumbernya | Otomatis bergulir ke bulan berikutnya |
| Urutan matahari dan bulan tidak diketahui | Ambiguitas tanda | Tebak berdasarkan bahasa server |
| Dengan waktu dan zona waktu | Gunakan protokol waktu independen | Cegat sepuluh karakter pertama secara acak |
| Bidang kosong | Perlakukan sesuai dengan aturan yang hilang | Lengkapi tanggal hari ini |
Memasukkan konfigurasi ke dalam pengujian regresi
Masukkan setidaknya tiga jenis nilai ke dalam set pengujian: hari kabisat resmi, hari kabisat ilegal, dan nilai salah format. Menjalankan contoh tandingan ini saat penerapan lebih efisien daripada sekadar memeriksa apakah file Skema ada. Jika layanan diimplementasikan dalam berbagai bahasa, set pengujian yang sama harus diverifikasi secara terpisah, dan jangan berasumsi bahwa perilaku default kedua validator adalah sama.
Tinjauan terjemahan mempertahankan tanggal aslinya
Saat menggunakan hasil ekstraksi tanggal untuk verifikasi terjemahan OmniDoc, disarankan untuk menyimpan nilai raw_text dan nilai yang dinormalisasi. Peninjau perlu melihat "apa isi aslinya" dan "bagaimana sistem menafsirkannya" untuk menentukan apakah perbedaannya terletak pada terjemahan, ekstraksi, atau konversi format.
Referensi: String dan format Skema JSON.
📊 Perbandingan inti
| Barang komparatif | Validator bawaan | Aktifkan FormatChecker secara eksplisit |
|---|---|---|
| Periksa ruang lingkup | Jenis dan struktur | Pemeriksaan tambahan untuk format deklarasiformat |
Kesimpulan tentang 2026-02-30 | Jangan berasumsi penolakan | Perlu dikonfirmasi dengan contoh tandingan |
| maksudnya ketika lewat | Ini tidak berarti semantik tanggalnya benar | Masih perlu mengecek penjelasan tanggal pada bisnis tersebut |
🎯 Metode mana yang cocok untuk Anda?
Jika Anda hanya perlu memastikan bidang tersebut berupa string atau terstruktur dengan benar
Validator default biasanya cukup, namun perlu diketahui bahwa validator tersebut tidak selalu memeriksa semantik tanggal.
Jika Anda perlu mengonfirmasi bahwa tanggal tersebut benar-benar ada
Aktifkan FormatChecker secara eksplisit dan verifikasi dengan contoh tandingan seperti 2026-02-30.
Jika Anda ingin memeriksa tanggal di file sumber
Pertama-tama konfirmasikan aturan sumber urutan hari dan bulan, lalu simpan teks asli dan nilai yang dinormalisasi.
Jika layanan Anda diterapkan dalam berbagai bahasa
Serangkaian pengujian yang sama dijalankan pada setiap implementasi.
❓ Pertanyaan yang Sering Diajukan (FAQ)
1. Skema ditulis format: date, kenapa tanggal buruk masih bisa lewat?
Cara penanganan format bergantung pada konfigurasi validator dan semantik tanggal belum tentu diperiksa secara default.
2. Mengapa 2026-02-30 merupakan nilai tes yang berguna?
Kelihatannya seperti sebuah tanggal, tapi Februari bukanlah hari ketiga puluh. Hanya memeriksa tampilannya saja akan melewatkan masalah seperti ini.
3. Apa yang terjadi jika nama format yang tidak diketahui digunakan?
Ini tidak boleh diperlakukan seolah-olah sudah diperiksa, dan kesalahan ejaan dapat memberi Anda rasa aman yang salah.
4. Bagaimana seharusnya 03/04/2026 dikonversi?
Wilayah asal, deskripsi bidang, atau protokol eksplisit diperlukan. Kalau tidak, mustahil untuk mengetahui apakah itu mewakili tanggal 4 Maret atau 3 April.
📝 Ringkasan
Lolos verifikasi hanya berarti data tersebut memenuhi aturan yang ditetapkan, namun tidak berarti arti setiap tanggalnya benar. Pertama-tama konfirmasikan cakupan pemeriksaan validator, lalu gunakan contoh tandingan dan aturan sumber untuk memperbaiki tanggal pemrosesan, sehingga hasilnya akan lebih dapat diandalkan.


