Di sesi kali ini saya akan melanjutkan penjelasan mengenai penanganan beberapa zona waktu di MySQL part-2. Dan di pejelasan di sini saya akan seketika lanjutkan dari sesi sebelumnya. Singkatnya, jikateman-teman telah menyimpannya di tanggal 13 April 2060 selaku tanggal lokal, itu tak akan mewakili waktu depan yang diinginkan di waktunya karena di awalnya dikerjakan 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 pada waktu setempat asli atau waktu UTC. Teman-teman mungkin pun perlu menyebutkan dengan jelas zona waktu hakekatnya bagi tanggal tersebut. Jadi ini akan mempengaruhi bagaimana teman-teman menyimpan data karena, tergantung di keperluan, teman-teman mungkin perlu mengetahui zona waktu yang tepat.
Apakah informasi akan disortir atau disaring oleh waktu setempat atau oleh perwakilan UTC ?
Bergantung di kasus pemakaian teman-teman, mungkin perlu memilah dan menampilkan informasi merujuk pada urutan kronologis kejadian. Oleh karena itu representasi UTC, yang adalah sebuah titik hakekatnya pada waktu, yaitu cara yang tepat bagi menyortir data ini.
Bagaimana apabila persyaratannya yaitu bagi mengurutkan data merujuk pada waktu setempat asli? Kemudian disortir oleh UTC tak akan berhasil. Ini pun berlaku bagi pemilahan menurut waktu setempat, seperti menampilkan film yang diputar di tanggal lokal tertentu seperti 2016-12-01. Sekiranya Sahabat memfilter hasilnya menggunakan tanggal ini sesuai keinginan dan membandingkannya dengan waktu UTC dan bukan waktu setempat, karenanya film yang dimulai di Los Angeles di 2016-12-01 23:00 waktu setempat akan disaring, seperti UTC Representasi yaitu 2016-12-02 07:00 UTC.Apa yang dimaksud dengan “hari ini”? Seperti poin sebelumnya, pertanyaan ini (dan segala hubungannya, seperti minggu depan, besok, tahun ini, dll.) Akan tergantung di program Sahabat. Katakan bahwa pengguna ketika ini menginginkan log mesin dari mesin di seluruh dunia dan antarmuka mempunyai tombol bagi “memperoleh log dari: today”. Waktu setempat yaitu 2016-10-07 16:00 America / Buenos_Aires (UTC-3). Apa itu “hari ini” bagi pengguna ini? Dapat jadi:
Ini akan menjadi dari 2016-10-07 00:00 hingga 2016-10-07 23:59:59 di waktu setempat, yang diterjemahkan ke waktu UTC, meliputi segala catatan dari 2016-10-07 03:00 hingga 2016-10 -08 02:59:59 UTC. (Perhatikan tanggal dan waktu pergeseran pada representasi UTC).
Pada contoh, tanggal pengguna ketika ini yaitu 2016-10-07 di waktu setempat. Sekiranya kita menggunakan itu selaku bagian tanggal UTC, “hari ini” akan meliputi segala catatan yang berkisar dari 2016-10-07 00:00 hingga 2016-10-07 23:59:59 di UTC. (Dibandingi dengan contoh sebelumnya, rentang ini tak mempunyai pergeseran tanggal.)
Pada contoh kami, tanggal pengguna ketika ini yaitu 2016-10-07 di waktu setempat. Jadi, saya menggunakan bagian itu saja dan memperoleh log apa saja yang telah diraih di kisaran 2016-10-07 00:00 hingga 2016-10-07 23:59:59 namun pada catatan waktu setempat. Jadi apabila sebuah rekaman di bagian lain dunia diraih di 2016-10-07 23:00:00 (UTC-11), yaitu 2016-10-08 10:00:00 di UTC, itu mesti diambil. (Perhatikan bahwa catatan ini tak akan diambil pada dua contoh lainnya.)Manipulasi Zona Waktu di MySQL Seluruh ini memaksakan keperluan bagi memanipulasi data tanggal agar sesuai dengan keperluan program. Hal ini dimungkinkan bagi memanipulasi zona waktu di MySQL dengan menggunakan kegunaan CONVERT_TZ (). Dari dokumentasi MySQL:
Ini dapat digunakan dengan dua cara – dengan menunjukkan zona waktu atau dengan secara eksplisit melewatkan offset selaku parameter, seperti yang dapat Sahabat lihat di contoh berikut:
Memperoleh waktu ketika ini di MySQL
Sebelum kita melihat pendekatan alternatif, mari kita pertimbangkan bagaimana kita memperoleh waktu ketika ini di MySQL. Beberapa kegunaan tanggal waktu tempat tinggal. Secara default, MySQL menggunakan zona waktu program lokal. Oleh karena itu memanggil kegunaan SEKARANG () akan mengambil waktu sekarang ini di zona waktu apapun yang ditetapkan server. Tetapi apabila teman-teman ingin memastikan dan konsisten mengenai hasilnya, mungkin teman-teman lebih bagus menggunakan UTC_TIMESTAMP (). Dari dokumen resmi:
Pendekatan yang Disarankan
Saya akan merekomendasikan menyimpan tanggal dan waktu MySQL selaku kolom DATETIME (baca ini bagi memahami alasannya) dan menyimpan zona waktu (seperti “America / Los_Angeles”) di kolom VARCHAR lainnya. Perhatikan bahwa saya TIDAK merekomendasikan agar Sahabat menyimpan offset UTC; Hal ini karena perubahan DST diterangkan sebelumnya. Yang terpenting, simpan waktu UTC di database.
Ini yaitu representasi sangat akurat dari suatu titik waktu yang dapat Sahabat miliki. Karena Sahabat pun mempunyai kolom zona waktu, Sahabat akan selalu mempunyai kemampuan bagi “merekonstruksi” tanggal / waktu lokal asli, bagus lewat kegunaan MySQL CONVERT_TZ () atau dari ahir program Sahabat, seperti yang digambarkan oleh potongan kode PHP berikut:
