Validator dan Pemformat Timestamp ISO 8601

Apa yang Dikaji Validator Ini

Pemvalidator ini dirancang untuk alur kerja pengembang praktis: tempelkan timestamp atau string tanggal, periksa apakah cocok dengan bentuk ISO 8601 yang diharapkan, dan tangkap masalah pemformatan yang jelas sebelum nilai dikirim ke API, disimpan di JSON, atau disalin ke dalam berkas konfigurasi. Ini memeriksa apakah nilai tampak seperti tanggal gaya ISO atau timestamp yang valid dan apakah peramban dapat menguraikannya ke dalam tanggal nyata bukan yang mustahil.

Apa yang Validator Ini Tidak Periksa

Sebuah string dapat secara struktural valid di sini dan masih salah untuk aplikasi Anda. Halaman ini tidak mengetahui aturan bisnis Anda, pemesanan acara, persyaratan skema API, atau apakah layanan hilir bersikeras pada ofset zona waktu, akhiran UTC Z, detik pecahan, atau format tanggal-saja. Ini membantu Anda menangkap kesalahan format, tetapi tidak menggantikan kontrak yang didefinisikan oleh sistem yang akhirnya akan mengkonsumsi timestamp.

Alasan Biasa Gagal Setem Masa ISO 8601

Kegagalan yang paling umum adalah sederhana: hilang pemisah T, menggunakan ruang di mana timestamp ketat mengharapkan T, mengetik bulan atau hari yang mustahil, mengabaikan offset zona waktu yang diperlukan, menambahkan teks trailing tambahan, atau menyalin nilai dengan ruang putih tersembunyi dari spreadsheet atau penampil log. Sebuah timestamp mungkin juga gagal karena terlihat dekat dengan ISO 8601 tetapi tidak termasuk potongan tepat yang diharapkan oleh sistem target Anda.

Teladan yang Diterima dan Ditolak

Contoh-contoh yang bagus termasuk timestamp UTC penuh seperti 2026-03-005T17:46:39Z dan nilai tanggal-saja seperti 2026-03-05 ketika tanggal adalah semua yang Anda butuhkan. Input yang ditolak sering kali mencakup nilai seperti 2026/03/05, timestamp dengan ruang tetapi tidak ada zona waktu, atau senar dengan medan waktu yang hilang sebagian. Membandingkan contoh lewat dan gagal berdampingan sering kali merupakan cara tercepat untuk melihat apakah masalah tersebut adalah tanda baca, notasi zona waktu, atau nilai kalender yang mustahil.

UTC, Ofset, dan Makna Z

Akhiran Z berarti UTC. Ofset eksplisit seperti +00:00 juga mewakili UTC, sementara nilai seperti -05:00 atau +02:00 mewakili jenis timestamp yang sama dengan ofset lokal yang berbeda. Dua senar dapat mewakili instan yang sama sambil terlihat berbeda di layar karena satu ditulis dalam UTC dan satu lagi ditulis dengan offset regional. Itu salah satu alasan pengawakutuan waktu sering kali membutuhkan validasi maupun interpretasi, bukan hanya pencocokan pola.

Tanggal-Hanya-Tanggalkan Masukan Tarikh-Waktu

Nilai tanggal-saja seperti 2026-03-0-05 dapat valid ISO 8601, tetapi tidak membawa zona waktu atau waktu. Itu mungkin dapat diterima untuk tanggal jatuh tempo, jangkauan pelaporan, dan lapangan kalender, tetapi tidak untuk timestamp acara, catatan audit, atau muatan API yang membutuhkan segera. Gunakan perbedaan ini untuk memutuskan apakah nilai hanya valid atau benar-benar cocok untuk sistem yang Anda uji.

Cara Memperbaiki Penanda Waktu yang Tidak Valid

Mulailah dengan memangkas nilai dan memeriksa pemisah. Kemudian, diakonfirmasi apakah sistem target mengharapkan tanggal hanya, timestamp UTC dengan Z, atau timestamp dengan ofset numerik eksplisit. Jika nilai itu berasal dari lembar kerja, ekspor log, atau lapangan UI yang disalin, hapus ruang tambahan dan konfirmasi bahwa bulan, hari, dan potongan waktu selesai. Masalah tanda baca kecil sering kali merupakan penyebab nyata dari hasil validasi yang gagal.

Kerahsiaan dan Validasi Lokal

Validasi wonder berjalan di peramban Anda sehingga Anda dapat memeriksa timestamp dari log, webhook, jadwal, dan sistem internal tanpa mengirimkannya ke pemeriksa timestamp pihak ketiga. Itu berguna ketika nilai itu sendiri sensitif, terikat pada insiden, atau bagian dari muatan Anda lebih suka tetap dalam sesi debug lokal.