Konverter ISO 8601 ke WIB

2026-09-26T15:30:45Z adalah 26 September 2026 pukul 22.30.45 WIB

Huruf Z di ujung waktu ISO 8601 berarti UTC (Waktu Universal Terkoordinasi), sedangkan WIB (Waktu Indonesia Barat) lebih cepat 7 jam dari UTC. Jadi waktu berakhiran Z cukup ditambah 7 jam untuk menjadi WIB. Untuk WITA (Waktu Indonesia Tengah) tambahkan 8 jam, dan untuk WIT (Waktu Indonesia Timur) tambahkan 9 jam. Sebaliknya, nilai yang berakhiran +07:00 sudah merupakan waktu WIB, sehingga tidak boleh ditambah 7 jam lagi.

Jika teks tanggal dan waktu ditempel pada kolom konverter di atas, formatnya dikenali otomatis, lalu bagian tanggal, waktu, pecahan detik, dan zona waktu ditandai dengan warna masing-masing. Pita di bawah jawaban menumpuk satu hari UTC dan satu hari di zona tujuan pada sumbu waktu yang sama, sehingga terlihat di mana tanggal berganti dan rentang UTC untuk satu hari WIB. Zona tujuan dapat diganti ke WITA atau WIT. Tampilan awal memakai WIB, dan log beberapa baris dapat diubah sekaligus.

Saat waktu UTC perlu diubah ke WIB

Server dan program sering bertukar waktu dalam UTC atau ISO 8601 dengan offset, karena nilainya tidak berubah menurut wilayah. Konversi diperlukan saat seseorang membaca nilai itu dan harus memastikan pukul berapa kejadiannya di Indonesia.

• Memeriksa respons API atau JSON: nilai yang berakhiran Z, seperti "createdAt": "2026-09-26T15:30:45.123Z", adalah UTC. Untuk mencocokkannya dengan laporan pelanggan tentang pesanan pukul 22.30 tadi malam, nilai itu harus diubah ke WIB.
• Membaca log server: bila jam server diatur ke UTC, log pun tercatat dalam UTC, misalnya [26/Sep/2026:15:30:45 +0000]. Waktu gangguan perlu diubah ke WIB agar urutannya sesuai dengan catatan lain.
• Melihat header email atau HTTP: nilai seperti Date: Sat, 26 Sep 2026 15:30:45 GMT, yang ditulis dengan nama hari dan nama bulan bahasa Inggris, menunjuk momen yang sama.
• Mencari data satu hari WIB di database: pada kolom yang disimpan dalam UTC, pesanan tanggal 26 September WIB berada di antara UTC 25 September pukul 17.00 dan 26 September pukul 17.00. Baris di bawah pita menyalin rentang ini sebagai kondisi SQL.
• Mengisi pengaturan dalam UTC: misalnya layanan yang menerima jadwal kirim atau waktu kedaluwarsa dalam ISO 8601 UTC, atau tanda tangan AWS yang memerlukan format dasar seperti 20260926T153045Z.

Cara menghitung: kurangi offset yang tertulis untuk kembali ke UTC, lalu tambah 7 jam

Waktu WIB = waktu yang tertulis − offset yang tertulis + 7 jam

1. Cari penanda zona waktu di ujung teks: Z (atau +00:00) berarti UTC, +05:30 berarti wilayah yang 5 jam 30 menit lebih cepat dari UTC, dan -04:00 berarti wilayah yang 4 jam lebih lambat. Jika tidak ada penanda sama sekali, teks saja tidak cukup untuk mengetahui waktu daerah mana yang dimaksud.
2. Kurangi offset untuk kembali ke UTC: 2026-09-26T08:00:00+05:30 dikurangi 5 jam 30 menit menjadi UTC pukul 02.30. Jika offsetnya negatif, tambahkan.
3. Tambahkan 7 jam pada UTC: UTC pukul 02.30 menjadi pukul 09.30 WIB. Untuk periode ketika offset Jakarta bukan +7, seperti +07:30 sebelum 1964, dipakai nilai pada masa itu (perubahan zona waktu Indonesia).
4. Jika melewati pukul 24, majukan tanggal satu hari: UTC 18.00 + 7 jam = 25.00, yaitu pukul 01.00 keesokan harinya. Sebaliknya, jika pengurangan 7 jam dari waktu WIB turun di bawah pukul 0, tanggalnya mundur satu hari.

Pecahan detik tidak berubah meskipun zona waktu berganti, karena offset hanya dalam satuan jam dan menit. Konverter ini juga menyalin digit yang diketik, seperti .123 atau .123456789, apa adanya.

Cara membaca teks ISO 8601 bagian demi bagian

If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00".RFC 3339 4.3 Unknown Local Offset Convention. Bagian 5.6 pada dokumen yang sama menambahkan bahwa T dan Z boleh ditulis dengan huruf kecil t dan z.

Format yang dibaca konverter ini

Format berikut dapat ditempel apa adanya pada kolom input. Spasi di awal dan akhir serta angka lebar penuh dirapikan otomatis.

Jika yang sering dikerjakan hanya angka, konverter timestamp Unix menampilkan pembedaan satuan dan rentang 32 bit dengan lebih rinci.

Contoh konversi

Mulai UTC pukul 17.00, WIB sudah keesokan harinya

WIB lebih cepat 7 jam dari UTC, sehingga 7 jam terakhir dalam satu hari UTC (17:00 sampai 23:59) jatuh pada tanggal berikutnya menurut WIB. Dengan kata lain, satu hari WIB berlangsung dari pukul 17.00 UTC hari sebelumnya sampai sebelum pukul 17.00 UTC hari itu. Untuk WITA batasnya pukul 16.00 UTC, dan untuk WIT pukul 15.00 UTC.

Karena itu, data yang direkap menurut tanggal UTC akan memasukkan catatan sebelum pukul 07.00 WIB ke hari sebelumnya. Untuk merekap menurut tanggal WIB, kueri rentang UTC dengan interval yang ujung akhirnya terbuka seperti berikut.

-- Satu hari WIB 2026-09-27
WHERE created_at >= '2026-09-26T17:00:00Z'
  AND created_at <  '2026-09-27T17:00:00Z'

Jika ujung akhirnya ditutup pada 23:59:59, pecahan detik sesudahnya (misalnya 23:59:59.5) akan terlewat. Karena itu, lebih aman menulis "kurang dari pukul 00.00 hari berikutnya".

Mengubah ke WIB di dalam kode

Di dalam program, memberi nama zona waktu (Asia/Jakarta) lebih tepat daripada menambah 7 jam sendiri, karena perubahan offset di masa lalu ikut ditangani.

When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.ECMA-262 21.4.1.32 Date Time String Format. Teks yang sama dibaca dengan zona waktu berbeda oleh JavaScript, bergantung pada ada tidaknya bagian waktu.

Zona waktu Indonesia tidak selalu seperti sekarang

Indonesia memakai tiga zona waktu: WIB (UTC+07:00), WITA (UTC+08:00), dan WIT (UTC+09:00). Dalam basis data zona waktu IANA (Asia/Jakarta, Asia/Makassar, Asia/Jayapura), offset ketiganya pernah berubah beberapa kali sebelum menetap pada nilai sekarang. Konverter ini mengikuti catatan itu dan menghitung dengan offset pada masa tersebut. Daftar di bawah mencatat saat setiap offset mulai berlaku, dalam UTC.

Dalam data IANA tidak ada perubahan offset ketiga zona itu sesudah tanggal terakhir di tabel, dan tidak ada waktu musim panas. Karena itu, nilai tanpa zona waktu tidak pernah menjadi "waktu yang tidak ada" atau "waktu yang muncul dua kali" pada zaman sekarang. Offset yang memuat detik, seperti +07:07:12 sebelum 1923, tidak dapat ditulis penuh dalam format RFC 3339 dan RFC 2822 yang hanya sampai menit, sehingga dua baris itu dikosongkan pada konverter untuk periode tersebut.

Kesalahan yang sering terjadi

• Menambah 7 jam lagi pada nilai +07:00: 2026-09-26T22:30:45+07:00 sudah merupakan waktu WIB. Menambah 7 jam akan menghasilkan pukul 05.30 keesokan harinya, yang jelas salah.
• Menganggap nilai tanpa zona waktu sebagai UTC: 2026-09-26 22:30:45 tidak mengandung informasi zona waktu. Periksa dulu apakah program penyimpannya menulis dalam WIB atau UTC, lalu pilih pengaturan "Nilai tanpa zona waktu dibaca sebagai" di atas.
• Hanya membandingkan tanggal: tanggal 26 September menurut UTC dan menurut WIB adalah dua hari yang bergeser 7 jam. Untuk statistik harian, tentukan lebih dulu memakai zona waktu yang mana.
• Salah menetapkan zona antara WIB, WITA, dan WIT: selisih antarzona hanya 1 jam, sehingga kesalahan mudah lolos. Pilih zona tujuan secara eksplisit pada konverter dan jangan hanya mengandalkan akhiran WIB.
• Memercayai singkatan seperti CST atau IST: CST dapat berarti waktu standar tengah Amerika (-06:00) atau waktu standar Tiongkok (+08:00), dan IST dipakai India, Irlandia, serta Israel. Konverter ini hanya membaca singkatan Amerika yang nilainya ditetapkan RFC 5322, dan meminta singkatan yang dipakai banyak negara ditulis ulang sebagai offset angka.

Keterbatasan

• Perhitungan zona waktu mengikuti data zona waktu IANA yang ada pada peramban yang dipakai. Tergantung versi datanya, offset pada masa yang sangat lampau atau pada wilayah yang baru berubah bisa berbeda.
• Tanggal nomor pekan seperti 2026-W39-6, tanggal urutan hari dalam tahun seperti 2026-269, dan penulisan yang urutan bulan dan harinya berbeda antarnegara seperti 09/26/2026 tidak dibaca.
• Detik kabisat seperti 23:59:60 tidak ada dalam waktu Unix, sehingga dihitung sebagai detik 0 pada menit berikutnya.
• Format asctime (Sat Sep 26 15:30:45 2026) dianggap UTC menurut standar HTTP, tetapi sebagian program mencetaknya dalam waktu setempat, sehingga format ini mengikuti pengaturan "Nilai tanpa zona waktu dibaca sebagai".
• Pecahan detik diterima sampai nanodetik (9 digit). Singkatan zona waktu yang dibaca hanyalah UTC, GMT, KST, JST, WIB, WITA, WIT, CET, CEST, dan singkatan Amerika dari RFC 5322.

Sumber

• 01IETF RFC 3339: Date and Time on the Internet: Timestamps4.3 -00:00 (selisih waktu setempat tidak diketahui), 5.6 tata bahasa date-time dan izin t, z huruf kecil serta pemisah spasi, 5.7 detik kabisat 60
• 02IETF RFC 5322: Internet Message Format3.3 date-time (hari harus cocok dengan tanggal, arti -0000), 4.3 nilai singkatan zona waktu lama UT, GMT, EST sampai PDT
• 03IETF RFC 9110: HTTP Semantics, 5.6.7 Date/Time FormatsContoh tanggal HTTP IMF-fixdate "Sun, 06 Nov 1994 08:49:37 GMT", format asctime dianggap UTC
• 04ECMA-262: 21.4.1.32 Date Time String FormatTanggal tanpa offset dibaca sebagai UTC, tanggal dan waktu dibaca sebagai waktu setempat. 21.4.4.41 format Date.prototype.toString
• 05Dokumentasi Python: datetime.fromisoformatMulai 3.11 membaca sebagian besar format ISO 8601, contoh '2011-11-04T00:05:23Z' menjadi UTC
• 06AWS: Penanganan tanggal Signature Version 4"The time stamp must be in UTC and use the following ISO 8601 format: YYYYMMDDTHHMMSSZ"
• 07nginx: ngx_http_log_module$time_local "local time in the Common Log Format"
• 08Dokumentasi PostgreSQL: 8.5.2 Date/Time OutputContoh keluaran gaya ISO "1997-12-17 07:37:16-08"
• 09IANA Time Zone DatabaseBerkas asia: catatan Asia/Jakarta, Asia/Makassar, dan Asia/Jayapura (perubahan offset 1923 sampai 1963)

Sumber diperiksa pada 2026-10-20. Data zona waktu diperbarui beberapa kali setiap tahun, dan waktu pada layar mengikuti versi yang ada pada peramban yang dipakai.

Pertanyaan yang sering diajukan

Alat yang sering dipakai bersama