Zona waktu tidak cocok: pemeriksaan konsistensi termurah di web
Dari semua pemeriksaan konsistensi yang bisa dijalankan situs web, membandingkan zona waktu adalah yang termurah. Ia hanya butuh satu panggilan JavaScript dan satu pencarian yang memang sudah dilakukan server. Ini juga salah satu alasan paling umum sebuah akun diperiksa lebih lanjut.
Dua zona waktu, dua sumber
Zona waktu pertama berasal dari alamat Anda. Server tahu dari mana permintaan datang dan memakai basis data geolokasi untuk memetakan alamat itu ke wilayah dan zona waktunya. Untuk koneksi dari Paris, itu Europe/Paris. Ini terjadi di server; browser Anda tidak punya suara dalam hal ini.
Yang kedua berasal dari browser Anda. Intl.DateTimeFormat().resolvedOptions().timeZone mengembalikan nama IANA yang dikonfigurasi pada sistem operasi, dan new Date().getTimezoneOffset() mengembalikan offset UTC saat ini. Jika mesin diatur ke Berlin, halaman melihat Europe/Berlin, terlepas dari mana paket datang.
Mengapa keduanya berbeda
Alasan yang wajar adalah perjalanan, laptop yang wilayah jamnya tidak pernah diubah, dan jaringan perusahaan yang keluar di negara lain. Alasan yang diperhatikan situs adalah proxy: browser di satu negara memakai alamat di negara lain, tanpa ada yang memikirkan jamnya. Paris dan Berlin berbagi offset, sehingga offset saja akan cocok; nama IANA tidak. Pemeriksaan yang membandingkan nama akan menangkapnya, itulah sebabnya diagnostik menampilkan nama dari browser dan nama dari alamat, bukan offset numerik.
Arti ketidakcocokan
Sendirian, tidak ada yang konklusif. Banyak orang sungguhan memicunya. Tetapi ini sinyal murah, dan sistem penilaian menjumlahkan sinyal-sinyal murah. Ketidakcocokan ditambah alamat yang diklasifikasikan sebagai hosting ditambah kandidat WebRTC di tempat ketiga adalah cerita yang berbeda dari ketidakcocokan saja.
Membuatnya sepakat
Ada dua cara mendapatkan hasil yang konsisten. Atur zona waktu sistem operasi agar sesuai dengan alamat, yang berhasil tetapi merepotkan saat beberapa profil memakai alamat berbeda. Atau biarkan profil browser menimpa zona waktu yang dilaporkannya, yang dilakukan browser berorientasi khusus: zona waktu profil mengikuti alamat yang dipakainya saat diluncurkan, sehingga kedua nama cocok secara otomatis. Pendekatan kedua juga harus mencakup offset saat ini, transisi waktu musim panas, dan string tanggal yang dilokalkan, karena skrip bisa membandingkan semuanya. Profil yang melaporkan Europe/Paris tetapi memformat tanggal dengan offset Berlin hanya memindahkan kontradiksinya.
Apa yang dicari dalam laporan
Diagnostik yang menampilkan "Zona waktu berdasarkan IP" dan "Zona waktu" berdampingan, dan menandainya saat berbeda, melakukan persis apa yang dilakukan pemeriksaan sebuah situs. Jika cocok, pemeriksaan lolos. Jika tidak, kini Anda tahu mana yang harus diubah. Dalam kedua kasus, perbandingannya sendiri yang berguna, bukan skor yang ditempelkan padanya.
