Konverter Zona Waktu

Bandingkan zona waktu di satu layar langsung

Konverter zona waktu gratis ini menempatkan setiap kota yang Anda pedulikan di satu layar. Setiap baris menampilkan waktu kota saat ini (atau yang dipilih), tanggal, offset UTC dan selisih dari kota dasar Anda, plus strip 24 jam yang selaras — setiap kolom mewakili momen yang sama di semua baris, sehingga membaca melintang menjawab 'jam berapa di sana saat di sini pukul 3 sore?' tanpa aritmetika apa pun.

Seret slider atau klik sel jam mana pun untuk memindahkan momen; setiap baris diperbarui secara langsung. Tidak ada muat ulang halaman, tidak ada formulir untuk dikirim, dan tidak perlu akun. Tambahkan kota tanpa batas dan susunan Anda disimpan di browser Anda untuk kunjungan berikutnya — berbeda dari World Time Buddy, yang membatasi tingkat gratis pada 4 lokasi dan memerlukan login.

Perencana rapat yang menampilkan tumpang tindih

Penjadwalan lintas zona waktu adalah masalah tumpang tindih, jadi strip jam diberi kode warna seperti perencana rapat: hijau untuk jam kerja inti (9–17), kuning untuk tepi (7–9 dan 17–21), dan redup untuk jam yang tidak diinginkan siapa pun. Kolom di mana setiap baris berwarna hijau adalah slot aman; kolom yang hijau di New York tetapi abu-abu tengah malam di Mumbai memberi tahu Anda untuk terus mencari.

Sudah menemukan slotnya? Klik dan tekan Salin waktu rapat — Anda mendapatkan pengumuman siap-tempel yang mencantumkan hari kerja, waktu lokal, dan offset UTC setiap peserta. Salin tautan berbagi mengirimkan seluruh susunan, dibekukan pada momen pilihan Anda, kepada siapa pun. Calendly dan Google Calendar keduanya menangani penjadwalan tetapi tidak ada yang menampilkan tumpang tindih berkode warna seperti kisi waktu berdampingan.

Waktu musim panas ditangani secara otomatis

Sebagian besar kesalahan konversi manual adalah kesalahan DST: selisih AS–India adalah 10,5 jam pada Januari tetapi 9,5 pada Juli; Inggris meninggalkan GMT untuk BST setiap musim semi; dan AS serta Eropa berpindah pada minggu yang berbeda. Konverter ini menghitung setiap waktu dari kota + tanggal menggunakan basis data zona waktu IANA yang terpasang di browser Anda, sehingga offset — termasuk zona setengah jam seperti IST (UTC+5:30) dan UTC+5:45 Nepal — selalu benar untuk tanggal yang Anda pilih.

Itulah juga mengapa Anda harus merencanakan dengan kota, bukan singkatan: 'EST' yang ditulis pada Juli biasanya salah satu jam, sementara 'New York' tidak pernah salah. Pilih tanggal rapat — bukan hari ini — dan strip mencerminkan offset hari itu, bukan yang saat ini.

EST ke IST, PST ke EST, GMT ke UTC — pasangan umum sekilas

Pasangan yang sering menjadi sekilas: EST ke IST adalah +10:30 (9 pagi New York = 7:30 malam Kolkata pada musim dingin), PST ke EST adalah +3 (tengah hari Los Angeles = 3 sore New York), London adalah +5 dari New York untuk sebagian besar tahun, dan Tokyo adalah +13/+14 tergantung DST AS. Tambahkan pasangan kota apa pun dan strip menampilkan seluruh hari berdampingan — termasuk penyeberangan garis tanggal di mana lencana '+1 hari' muncul.

Bagi tim jarak jauh, berlabuh pada UTC adalah kebiasaan paling bersih: nyatakan rapat sekali dalam UTC, lalu biarkan setiap orang membaca barisnya sendiri. Targetkan setidaknya ~4 jam waktu kerja yang tumpang tindih per hari untuk kolaborasi yang erat, dan rotasikan slot yang canggung ketika tidak ada jendela bersih yang cocok untuk semua orang.

Gratis, tanpa batas dan privat — tanpa unggah, tanpa akun

Alat populer membatasi tingkat gratis. World Time Buddy membatasi pengguna gratis hingga 4 lokasi sebelum meminta pembayaran. Savvy Time memerlukan akun untuk menyimpan pengaturan Anda. Di sini semuanya gratis dan berjalan langsung: kota tanpa batas, penggeseran slider, klik-untuk-atur jam, tautan berbagi, dan penyalin pengumuman rapat.

Seluruh perencana berjalan di sisi klien — daftar kota Anda tidak pernah meninggalkan perangkat Anda, dan setelah dimuat juga berfungsi offline. Tidak ada yang perlu didaftarkan dan tidak ada data yang dikirim ke server. Untuk freelancer yang memberi kutipan waktu panggilan ke klien di luar negeri, tim rekayasa jarak jauh di tiga benua, atau siapa pun yang mengecek jam berapa di Tokyo sebelum menelepon — jawabannya sekilas.

Bagaimana zona waktu sebenarnya bekerja: UTC, offset, dan basis data IANA

UTC (Coordinated Universal Time) adalah jam global tempat setiap zona waktu lainnya diukur. Ini menggantikan GMT (Greenwich Mean Time) sebagai standar internasional pada 1960, ketika adopsi jam atom memungkinkan penjagaan waktu hingga beberapa miliar detik per hari — jauh melampaui apa yang bisa dijamin definisi tengah-hari-matahari GMT. GMT masih digunakan sebagai nama zona waktu di Inggris saat musim dingin, tetapi ketika insinyur dan badan standar membutuhkan referensi yang tidak ambigu, mereka mengatakan UTC.

Setiap zona waktu bernama dinyatakan sebagai offset UTC — angka bertanda jam (dan kadang menit) ditambahkan ke atau dikurangkan dari UTC untuk mendapatkan waktu sipil lokal. New York pada musim dingin adalah UTC−5; Tokyo adalah UTC+9. Offset saja tidak cukup, karena offset yang sama bisa berlaku untuk wilayah berbeda dengan aturan waktu musim panas berbeda — dan aturan itu berubah ketika pemerintah memutuskan untuk mengubahnya. Itulah mengapa IANA Time Zone Database (juga disebut tzdata atau basis data Olson) diciptakan. Ini menetapkan pengidentifikasi unik — seperti America/New_York atau Asia/Kolkata — untuk setiap kombinasi riwayat offset dan aturan DST. Setiap sistem operasi utama, runtime bahasa pemrograman, dan browser web menyertakan salinan basis data ini dan memperbaruinya setiap kali pemerintah mengubah jamnya.

Konsekuensi praktisnya adalah singkatan seperti EST atau IST bersifat ambigu. 'IST' mengacu pada India Standard Time, Israel Standard Time, dan Irish Standard Time — tiga zona dengan offset berbeda. 'EST' adalah Eastern Standard Time di AS, tetapi juga waktu musim dingin beberapa negara Karibia yang tidak pernah bergeser untuk DST. Menggunakan pengidentifikasi IANA sebagai gantinya — America/New_York, Asia/Kolkata, Europe/Dublin — menghilangkan ambiguitas apa pun, karena setiap pengidentifikasi memetakan ke tepat satu set aturan historis dan masa depan.

Waktu musim panas: sejarah, politik, dan mimpi buruk programmer

Waktu musim panas (DST) pertama kali diperkenalkan selama Perang Dunia I, ketika Jerman dan Austria mulai memajukan jam mereka satu jam pada April 1916 untuk mengurangi konsumsi batu bara untuk pencahayaan buatan. Inggris mengikuti beberapa minggu kemudian. Praktik ini menyebar, tidak digunakan lagi setelah perang, dihidupkan kembali selama Perang Dunia II, lalu dilembagakan di banyak negara selama krisis energi tahun 1970-an. Ide intinya adalah menggeser satu jam siang hari dari pagi hari — saat kebanyakan orang tidur — ke malam hari, saat orang aktif dan menggunakan listrik.

Di Amerika Serikat, jam dimajukan satu jam pada Minggu kedua Maret dan mundur pada Minggu pertama November, jadwal yang telah berlaku sejak Energy Policy Act 2005. Arizona (kecuali Navajo Nation) dan Hawaii sama sekali tidak menerapkan DST — Arizona karena panas gurunnya membuat siang hari malam yang diperpanjang menjadi beban aktif, bukan manfaat. Di Eropa, Minggu terakhir Maret dan Minggu terakhir Oktober adalah tanggal transisi. UE memilih pada 2019 untuk menghapus perubahan jam dua tahunan, memungkinkan setiap negara anggota memilih waktu standar atau musim panas permanen, tetapi hingga pertengahan 2026 arahan itu belum diterapkan karena ketidaksepakatan koordinasi. Sebagian besar dunia — sebagian besar Asia, Afrika, Amerika Selatan, dan hampir semua wilayah khatulistiwa — tidak menerapkan DST sama sekali, karena variasi musiman matahari terbit dan terbenam kecil di dekat khatulistiwa.

Bagi pengembang perangkat lunak, DST adalah sumber bug yang abadi. Transisi dari waktu standar ke waktu musim panas menciptakan celah: di New York pada Minggu kedua Maret, jam melompat dari 1:59 pagi langsung ke 3:00 pagi, sehingga 2:30 pagi tidak ada. Transisi musim gugur menciptakan tumpang tindih: jam mundur dari 1:59 pagi kembali ke 1:00 pagi, sehingga 1:30 pagi terjadi dua kali. Perangkat lunak penjadwalan yang menyimpan waktu sebagai string jam dinding lokal alih-alih UTC akan salah berfungsi selama jendela ini — menghasilkan peringatan kalender ganda, penagihan ganda pada sistem pembayaran, atau tugas yang hilang dalam penjadwal cron. Perbaikan universalnya adalah menyimpan semuanya dalam UTC dan mengonversi ke waktu lokal hanya saat ditampilkan.

Offset setengah jam dan 45 menit: mengapa beberapa zona tidak jatuh tepat jam

Kebanyakan orang berasumsi zona waktu berubah dalam langkah jam penuh, tetapi sekitar 15% populasi dunia tinggal di zona dengan offset pecahan. Contoh paling banyak penduduknya adalah India Standard Time (IST, UTC+5:30), yang mencakup seluruh subbenua — sekitar 1,4 miliar orang dalam satu zona dengan offset 30 menit. Zona terpadu diperkenalkan di bawah administrasi kolonial Inggris pada 1905 dan dipertahankan setelah kemerdekaan karena membagi negara di dua zona jam penuh akan menempatkan garis tengah timur-barat melalui wilayah berpenduduk padat, menciptakan kompleksitas yang tidak perlu. Sri Lanka (UTC+5:30), Iran (UTC+3:30), dan Afghanistan (UTC+4:30) masing-masing menggunakan offset 30 menit karena alasan geografis dan politik serupa.

Nepal Standard Time (NPT, UTC+5:45) adalah satu-satunya zona offset 45 menit di dunia. Ini ditetapkan pada 1986 untuk membedakan Nepal dari India (UTC+5:30) dan China (UTC+8:00), menekankan kemerdekaan nasional. Kepulauan Chatham, wilayah Selandia Baru, berada di UTC+12:45 (UTC+13:45 selama musim panas DST mereka), menjadikannya zona waktu berpenghuni paling timur di Bumi. Kepulauan Marquesas (UTC−9:30) di Polinesia Prancis adalah outlier 30 menit lainnya di Pasifik.

Bagi siapa pun yang melakukan aritmetika secara manual, zona pecahan adalah jebakan. Menambahkan 5:30 ke 09:30 UTC memberikan 15:00 IST — cukup mudah. Tetapi mengurangkan IST dari EDT (UTC−4) berarti selisihnya adalah 9 jam 30 menit pada musim panas, bukan angka bulat. Konverter yang menghitung dari zona IANA bernama menangani semua ini secara tak terlihat, itulah mengapa menggunakan alat alih-alih tabel pencarian sangat berharga ketika salah satu kota yang terlibat adalah Kolkata, Teheran, Kabul, atau Kathmandu.

Pemrograman dengan zona waktu: simpan UTC, tampilkan lokal

Aturan paling penting dalam penyimpanan waktu perangkat lunak adalah: simpan setiap timestamp dalam UTC, konversi ke waktu lokal hanya saat ditampilkan. Melanggar aturan ini adalah akar penyebab sebagian besar bug zona waktu dalam sistem produksi. Konstruktor new Date() JavaScript, ketika diberi string tanggal tanpa offset eksplisit, menafsirkannya dalam waktu lokal mesin yang menjalankan kode — yang berarti string yang sama menghasilkan momen berbeda dalam UTC tergantung di mana server dihosting. Alternatif yang aman adalah selalu menggunakan format ISO 8601 dengan penanda UTC eksplisit: 2024-06-20T14:30:00Z, di mana Z di akhir secara tak ambigu menandakan UTC.

Pada tingkat terendah, sebagian besar sistem menyimpan waktu sebagai Unix timestamp: jumlah detik yang telah berlalu sejak 1970-01-01T00:00:00Z (epoch Unix). Unix timestamp selalu dalam UTC menurut definisi dan aman untuk dibandingkan, diurutkan, dan dilakukan aritmetika tanpa pengetahuan zona apa pun. Masalah Tahun 2038 yang terkenal muncul karena sistem lawas menyimpan Unix timestamp sebagai bilangan bulat bertanda 32-bit, yang meluap pada 2038-01-19T03:14:07Z. Sistem modern menggunakan bilangan bulat 64-bit, yang mendorong tanggal meluap miliaran tahun ke masa depan.

Ekosistem bahasa telah berkembang secara signifikan untuk mengatasi jebakan ini. Kelas java.util.Date dan Calendar asli Java memiliki API yang sangat membingungkan — Date menyimpan milidetik sejak epoch tetapi metode getYear()-nya mengembalikan tahun sejak 1900 — dan digantikan di Java 8 oleh paket java.time, yang menyediakan tipe berbeda untuk Instant (momen UTC), LocalDateTime (tanggal-waktu tanpa zona), ZonedDateTime (tanggal-waktu dengan zona IANA penuh), dan ZoneOffset. Di Python, datetime.now() pustaka standar mengembalikan datetime naif tanpa informasi zona; praktik terbaik adalah memanggil datetime.now(timezone.utc) atau menggunakan modul zoneinfo (ditambahkan di Python 3.9) alih-alih pytz pihak ketiga, yang memiliki API localize() yang secara halus tidak standar dan membingungkan pengguna baru. Di seluruh platform, pelajarannya sama: bersikaplah eksplisit tentang zona di setiap batas — saat membaca input pengguna, saat menulis ke database, dan saat memformat untuk ditampilkan.