Bug di tahun 2038

Permasalahan ini saya temukan ketika salah satu klien saya mengabarkan adanya sebuah bug dari aplikasi yang saya buat, bug yang dimaksud adalah tahun 2038.

Apa maksudnya ini?

Bug ini diketemukan saat akan meng-update tahun yang lebih dari 2038, sebagai contoh, saya akan update tanggal di aplikasi dari 17/02/2015 22:05:00 menjadi 17/02/2052 22:05:00. Maka yang tersimpan di database berubah menjadi 19/01/2038 03:14:07 (dan setiap tahun yang lebih dari 2038, pasti akan otomatis me-reset menjadi 19/01/2038 03:14:07)

Mengapa seperti ini?

Wikipedia: http://en.wikipedia.org/wiki/Year_2038_problem
Other resources:
http://2038bug.com/
https://www.google.com/search?q=2038

Jika anda para developer menggunakan tipe data integer (INT) untuk menyimpan tanggal dan waktu dengan menggunakan fungsi TIMESTAMP, maka anda pasti menemukan masalah ini.

Seperti yang dikutip dari Wikipedia: “The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and this number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970“.

Maksud dari kutipan tersebut adalah adanya sebuah isu dari data storage untuk menyimpan data dengan fungsi TIMESTAMP jika menggunakan 32-bit integer (INT), karena range integer adalah −2,147,483,648 sampai 2,147,483,647 dan menggunakan unix epoch (TIMESTAMP), maka tepat di titik batas maksimal nilai integer tersebut (2147483647) akan otomatis me-reset menjadi (−2147483648) yang jika dikonversi menjadi DATETIME: 2147483647 (19/01/2038 03:14:07) dan −2147483648 (13/12/1901 20:45:52) waktu UTC.

Coba anda perhatikan gambar berikut

Sistem akan otomatis me-reset bilangan desimal dikarenakan batas maksimum untuk tipe data integer (INT)

Cukup jelas jika anda memperhatikan gambar diatas, sistem me-reset otomatis bilangan desimal di hitungan maksimal tipe data integer (2147483647) kembali menjadi (−2147483648).

Solusi

Bagi anda yang mungkin pernah mengalami kasus seperti saya, ada beberapa solusi untuk memperbaiki permasalahan ini:

  1. Ubah tipe data menjadi BIGINT
    Ya, mengubah INT menjadi BIGINT menyelesaikan permasalahan ini, dimana range di kedua tipe data ini sangat jauh berbeda: INT (−2,147,483,648 sampai 2,147,483,647) sedangkan BIGINT (−9,223,372,036,854,775,808 sampai 9,223,372,036,854,775,807)
  2. Ubah tipe data menjadi DATETIME
    Jika anda ingin cara yang lebih mudah, ubah tipe data menjadi DATETIME, namun anda harus membuat fungsi penyimpanan data ke MySQL tidak lagi menggunakan TIMESTAMP, namun dengan menggunakan fungsi date. Contoh: date(“Y-m-d H:i:s”). Namun, repot kan kalau harus mengkonversi data-data yang sudah tersimpan menjadi DATETIME? 😀
  3. Solusi dari beberapa sumber
    Wikipedia: http://en.wikipedia.org/wiki/Year_2038_problem#Solutions
    2038bug.com: http://2038bug.com/index.php/articles/39-developer/61-what-can-i-do-as-a-developer

Kalau saya sih, pakai solusi nomor 1.

Beberapa Referensi

http://en.wikipedia.org/wiki/Year_2038_problem
http://en.wikipedia.org/wiki/Unix_time
http://en.wikipedia.org/wiki/Integer_%28computer_science%29

Semoga membantu 🙂

Content Protection by DMCA.com