Pada sesi kali ini saya akan melanjutkan penjelasan tentang penanganan beberapa zona waktu di MySQL part-2. Dan pada pejelasan di sini saya akan langsung lanjutkan dari sesi sebelumnya. Singkatnya, jikateman-teman sudah menyimpannya pada tanggal 13 April 2060 sebagai tanggal lokal, itu tidak akan mewakili masa depan yang diinginkan pada waktunya karena pada awalnya dibuat dengan offset -7hs dan bukan -8hs.

Bagaimana data ini akan ditampilkan?

Terkadang teman-teman perlu menunjukkan tanggal dan waktu di waktu setempat pengguna. Atau teman-teman mungkin perlu menampilkannya dalam waktu setempat asli atau waktu UTC. Teman-teman mungkin juga perlu menyebutkan dengan jelas zona waktu sebenarnya untuk tanggal tersebut. Jadi ini akan mempengaruhi bagaimana teman-teman menyimpan data karena, tergantung pada kebutuhan, teman-teman mungkin perlu mengetahui zona waktu yang tepat.

Apakah informasi akan disortir atau disaring oleh waktu setempat atau oleh perwakilan UTC ?

Bergantung pada kasus penggunaan teman-teman, mungkin perlu memilah dan menampilkan informasi berdasarkan urutan kronologis kejadian. Oleh karena itu representasi UTC, yang merupakan titik sebenarnya dalam waktu, adalah cara yang tepat untuk menyortir data ini.

Bagaimana jika persyaratannya adalah untuk mengurutkan data berdasarkan waktu setempat asli? Kemudian disortir oleh UTC tidak akan berhasil. Ini juga berlaku untuk pemilahan menurut waktu setempat, seperti menampilkan film yang diputar pada tanggal lokal tertentu seperti 2016-12-01. Jika Anda memfilter hasilnya menggunakan tanggal ini sesuai keinginan dan membandingkannya dengan waktu UTC dan bukan waktu setempat, maka film yang dimulai di Los Angeles pada 2016-12-01 23:00 waktu setempat akan disaring, seperti UTC Representasi adalah 2016-12-02 07:00 UTC.Apa yang dimaksud dengan “hari ini”? Seperti poin sebelumnya, pertanyaan ini (dan semua hubungannya, seperti minggu depan, besok, tahun ini, dll.) Akan tergantung pada aplikasi Anda. Katakan bahwa pengguna saat ini menginginkan log mesin dari mesin di seluruh dunia dan antarmuka memiliki tombol untuk “mendapatkan log dari: today”. Waktu setempat adalah 2016-10-07 16:00 America / Buenos_Aires (UTC-3). Apa itu “hari ini” untuk pengguna ini? Bisa jadi:

Ini akan menjadi dari 2016-10-07 00:00 sampai 2016-10-07 23:59:59 di waktu setempat, yang diterjemahkan ke waktu UTC, mencakup semua catatan dari 2016-10-07 03:00 sampai 2016-10 -08 02:59:59 UTC. (Perhatikan tanggal dan waktu pergeseran dalam representasi UTC).

Dalam contoh, tanggal pengguna saat ini adalah 2016-10-07 di waktu setempat. Jika kita menggunakan itu sebagai bagian tanggal UTC, “hari ini” akan mencakup semua catatan yang berkisar dari 2016-10-07 00:00 sampai 2016-10-07 23:59:59 di UTC. (Dibandingkan dengan contoh sebelumnya, rentang ini tidak memiliki pergeseran tanggal.)

Dalam contoh kami, tanggal pengguna saat ini adalah 2016-10-07 di waktu setempat. Jadi, saya menggunakan bagian itu saja dan mendapatkan log apa saja yang telah dihasilkan di kisaran 2016-10-07 00:00 sampai 2016-10-07 23:59:59 namun dalam catatan waktu setempat. Jadi jika sebuah rekaman di bagian lain dunia dihasilkan pada 2016-10-07 23:00:00 (UTC-11), yaitu 2016-10-08 10:00:00 di UTC, itu harus diambil. (Perhatikan bahwa catatan ini tidak akan diambil dalam dua contoh lainnya.)Manipulasi Zona Waktu di MySQL Semua ini memaksakan kebutuhan untuk memanipulasi data tanggal agar sesuai dengan kebutuhan aplikasi. Hal ini dimungkinkan untuk memanipulasi zona waktu di MySQL dengan menggunakan fungsi CONVERT_TZ (). Dari dokumentasi MySQL:

Ini dapat digunakan dengan dua cara – dengan menunjukkan zona waktu atau dengan secara eksplisit melewatkan offset sebagai parameter, seperti yang dapat Anda lihat pada contoh berikut:

Mendapatkan waktu saat ini di MySQL

Sebelum kita melihat pendekatan alternatif, mari kita pertimbangkan bagaimana kita mendapatkan waktu saat ini di MySQL. Beberapa fungsi tanggal waktu alamat. Secara default, MySQL menggunakan zona waktu sistem lokal. Oleh karena itu memanggil fungsi SEKARANG () akan mengambil waktu sekarang di zona waktu apapun yang ditetapkan server. Tetapi jika teman-teman ingin memastikan dan konsisten tentang hasilnya, mungkin teman-teman lebih baik menggunakan UTC_TIMESTAMP (). Dari dokumen resmi:

Pendekatan yang Disarankan

Saya akan merekomendasikan menyimpan tanggal dan waktu MySQL sebagai kolom DATETIME (baca ini untuk memahami alasannya) dan menyimpan zona waktu (seperti “America / Los_Angeles”) di kolom VARCHAR lainnya. Perhatikan bahwa saya TIDAK merekomendasikan agar Anda menyimpan offset UTC; Hal ini karena perubahan DST dijelaskan sebelumnya. Yang terpenting, simpan waktu UTC di database.

Ini adalah representasi paling akurat dari suatu titik waktu yang dapat Anda miliki. Karena Anda juga memiliki kolom zona waktu, Anda akan selalu memiliki kemampuan untuk “merekonstruksi” tanggal / waktu lokal asli, baik melalui fungsi MySQL CONVERT_TZ () atau dari akhir aplikasi Anda, seperti yang digambarkan oleh potongan kode PHP berikut:

Ini juga akan menghasilkan kueri efisien yang dapat menggunakan rentang dan pengurutan UTC.

Sampai di sini penjelasan saya mengenai penanganan beberapa zona waktu di MySQL, semoga bermanfaat.