Bagaimana menangani tanggal dan waktu tanpa amukan zona waktu ...

Tanggal, waktu, dan zona waktu adalah hal yang merepotkan.

Daylight saving, atau “waktu musim panas” seperti yang juga biasa dikenal, membuat keadaan menjadi lebih buruk, karena banyak negara mengubah jam mereka dua kali setahun untuk menggeser waktu matahari terbit dan terbenam yang tampak dalam kaitannya dengan hari kerja biasa.

Di Inggris, misalnya, jam kami disetel ke Waktu Rata-Rata Greenwich ketika Tahun Baru tiba, tetapi kami memutarnya maju ke GMT+1 pada akhir Maret, dan kembali ke GMT lagi pada akhir Oktober.

Sebagian besar Amerika Utara melakukan sesuatu yang sangat, sangat mirip, namun sangat berbeda, mengatur tanggal di mana jam berubah menjadi awal November dan awal Maret sebagai gantinya. (Dua negara kami dulunya selaras, tetapi sedikit menjauh di awal abad ini.)

Jadi rekan-rekan kami di Boston selalu lima jam di belakang kami di Oxfordshire, kecuali untuk periode singkat setiap musim gugur (atau musim gugur, mengingat kami bahkan tidak dapat menyepakati nama-nama musim dalam bahasa umum kami, apalagi penyelarasan jam kami) dan musim semi ketika mereka tidak.

Penentang penghematan siang hari menganggapnya sebagai kerumitan sia-sia yang tidak kita butuhkan di era internet, yang agak ironis mengingat perangkat era internet umumnya dapat menyesuaikan diri secara otomatis. Pendukung sistem mencatat bahwa, bagi banyak orang, menggeser hari kerja mereka agar sesuai dengan musim tidak mungkin lagi, karena hari-hari mereka diatur oleh jam dan bukan oleh posisi harian matahari, jadi menggeser jam agar sesuai dengan musim. merupakan alternatif yang paling sederhana.

Pergeseran DST dianggap berbahaya

Memang, masalah waktu musim panas meningkat sepanjang minggu ini ketika Chili memutuskan untuk mengubah tanggal saklar jam biasa untuk sementara (untuk menambah kerumitan, jam berubah ke arah lain di bawah khatulistiwa, karena musimnya terbalik).

Perubahan sementara diumumkan untuk menghindari kebingungan pada hari referendum konstitusi negara baru-baru ini.

Referendum berlangsung pada 04 September 2022, hari di mana jam biasanya bergerak maju untuk musim panas.

Oleh karena itu, pergantian jam ditunda selama seminggu, agar orang yang lupa menyetel ulang jam mereka sebelum tidur pada Sabtu malam mungkin salah membaca waktu pada hari Minggu, dan akhirnya tiba di tempat pemungutan suara setempat setelah jam tutup, tanpa menyadarinya. terlambat satu jam karena jam mereka lambat satu jam.

Bahkan Microsoft merasa perlu untuk memperingatkan penggunanya bahwa jam Windows, ketepatan waktu sistem operasi, jadwal rapat, dan lainnya mungkin dibuang begitu saja, mengingat bahwa pemerintah Chili tidak mengumumkan perubahan sementara ini hingga bulan lalu, sehingga memerlukan pembaruan menit terakhir ke basis data zona waktu Windows.

Bagaimana jika jam Anda terkunci?

Setidaknya pengguna sistem operasi tradisional dapat membuat penyesuaian zona waktu sementara sendiri jika diperlukan.

Beberapa perangkat sepenuhnya bergantung pada pembaruan firmware untuk menampilkan waktu lokal dengan benar.

Misalnya, kami memiliki "komputer" sepeda mini yang kami gunakan sebagai kompas dan pelacak jarak saat melakukan perjalanan (menakjubkan betapa lancar dan alaminya Anda dapat bernavigasi tanpa pernah melihat peta jika Anda dapat melacak waktu, jarak dan arah)…

…dan meskipun Anda dapat mengutak-atik semua jenis pengaturan yang tersimpan di perangkat, seperti massa tubuh Anda (tampaknya digunakan untuk menebak output daya Anda), pengaturan peta, format referensi lokasi, ukuran font, dan banyak lagi, satu hal yang tidak dapat Anda lakukan lakukan adalah mengatur tanggal dan waktu secara manual.

Tidak ada cara untuk melakukannya, setidaknya untuk aplikasi bawaan, dan Anda bahkan tidak dapat mengubah atau meretasnya sendiri, karena semuanya menjalankan versi Linux yang ditandatangani secara digital dan dikunci firmware.

Anda dapat menulis aplikasi tambahan Anda sendiri, dan mereka dapat menampilkan tanggal dan waktu sesuka mereka, tetapi mereka harus dikompilasi untuk dijalankan di mesin virtual khusus di dalam kotak pasir yang agak terbatas.

Teorinya adalah jika perangkat bekerja dengan benar, ia mengetahui waktu absolut melalui penerima GPS-nya, dengan akurasi yang jauh lebih baik daripada kronometer mekanis terbaik, terbesar, termahal, dan paling kompleks yang pernah dibuat.

Ia juga mengetahui di mana Anda berada di planet ini dengan akurasi jauh di bawah 10 meter (Anda dengan jelas memberi tahu di jalur mana Anda berada, atau melihat di mana Anda menyalip bus, ketika Anda melihat kembali perjalanan yang Anda rekam), sehingga ia dapat menghitung mana zona waktu fisik tempat Anda berada, dan atur waktu lokal dengan tepat juga.

Yah, ia dapat melakukannya jika basis data zona waktunya, yang menunjukkan lokasi tepat batas zona waktu, dan perpindahan yang diperlukan dari UTC (pengganti GMT modern pada arloji digital) mutakhir.

Jika tidak, Anda mungkin harus menambah atau mengurangi satu jam di kepala Anda, jika perangkat salah.

Atau setengah jam, karena beberapa wilayah menggunakan zona waktu 30 menit.

(Mengejutkan betapa banyak orang menolak untuk menerima bahwa zona waktu non-bilangan bulat ada, bersikeras bahwa “semua zona waktu legal berjalan dalam hitungan jam”, yang akan menjadi berita bagi siapa pun di India atau Australia Selatan.)

Atau 15 menit.

(Cobalah mengunjungi Nepal atau Eucla.)

Akankah pelarangan musim panas membantu?

Mereka yang tidak menyukai penghematan siang hari, baik karena mereka menganggapnya sebagai penghinaan terhadap tatanan alam, atau karena mereka tidak pernah dapat mengingat untuk mengubah jam yang dioperasikan secara manual di rumah mereka, akan meyakinkan kita semua bahwa melarang "waktu musim panas" akan menyelesaikan semua masalah ini dengan rapi.

Tetapi tidak akan menyelesaikan masalah bagaimana memahami log komputer, dan cara menggunakannya dalam pemecahan masalah TI, terutama dalam respons ancaman keamanan siber, di mana urutan di mana hal-hal terjadi bisa menjadi sangat penting.

Misalnya, jika log menunjukkan bahwa penjahat hampir pasti masuk pada pukul 03:30 pada Selasa malam, berdasarkan eksploitasi yang pertama kali disalahgunakan pada saat itu…

…apakah stempel waktu pembuatan akun baru 03:00 benar-benar terjadi sebelum eksploitasi dipicu, atau mungkinkah setelah itu?

Apakah perubahan konfigurasi diberi cap waktu 04:00 yang perlu diputar kembali, karena terjadi setelah serangan dimulai, atau apakah perubahan tersebut perlu Anda pertahankan karena log didenominasi dalam zona waktu yang berbeda?

Apa yang harus dilakukan?

Ada satu hal yang dapat Anda lakukan untuk membantu, baik sebagai pembuat file log dan konsumen file log.

Selalu kurangi stempel waktu ke UTC (waktu terkoordinasi universal), sehingga memfaktorkan zona waktu dari file log Anda, dan selalu rekam stempel waktu dalam format yang sederhana, tidak ambigu, dan dapat diurutkan berdasarkan abjad.

Sederhananya: berkonsultasi, RFC 3339, dan berpegang teguh pada Waktu Zulu cap waktu di mana-mana.

Ini terlihat seperti ini:

  2022-09-08T17:30:00.00000Z

Tanggal selalu memiliki empat digit tahun, jadi tidak ada risiko menemukan kembali bug milenium.

Waktu tidak membutuhkan AM dan PM (komputer dapat menghitung hingga 24 setidaknya semudah Anda menghitung hingga 12), yang menghilangkan ambiguitas.

Dan itu Z di akhir menunjukkan bahwa tanggal dan waktu ditampilkan tidak menerapkan penyesuaian zona waktu, sehingga setiap dua Waktu Zulu entri log dapat langsung dibandingkan untuk menentukan urutan di mana mereka terjadi.

Respons ancaman jauh lebih mudah, dan jauh lebih aman, jika stempel waktu Anda tidak ambigu, jadi kami merekomendasikan pendekatan ini kepada semua orang.

---

BACAAN LEBIH LANJUT TENTANG
PENTINGNYA KEJELASAN DALAM FORMAT TIMESTAMP

---

BEBERAPA ALASAN CERAH (BELUM ASLI) UNTUK RFC 3339