Anda menjalankan kueri diagnostik waktu ini di server MySQL Anda.
select @@time_zone, now(), utc_timestamp()
Jelas dari waktu lokal dan waktu utc Anda bahwa pengaturan zona waktu sistem mesin server Anda adalah 'Kanada/Gunung', dan perangkat lunak server MySQL tidak memiliki pengaturan zona waktu sendiri.
Jika Anda mengambil tabel dan memindahkannya tanpa perubahan ke server di beberapa zona waktu terdekat, Anda dapat selalu memperbarui perangkat lunak untuk mengeluarkan perintah
set time_zone = 'Canada/Mountain';
tepat setelah Anda terhubung dari perangkat lunak Anda. Ini akan membuat koneksi MySQL baru Anda berperilaku seperti koneksi Anda saat ini berdasarkan zona waktu. Jika Anda memiliki server MySQL, Anda dapat mengatur zona waktu default sesuai dengan petunjuk di halaman ini. http://dev.mysql.com/doc /refman/5.5/en/time-zone-support.html
Sekarang, inilah cerita tentang tipe data waktu. DATE , TIME , dan DATETIME semuanya tidak mengetahui zona waktu . Setelah Anda menyimpan nilai tanggal/waktu, Anda akan mendapatkannya kembali dengan nilai yang sama meskipun Anda mengubah pengaturan zona waktu.
TIMESTAMP tipe data sensitif zona waktu . Item data tersebut selalu disimpan dalam UTC, juga dikenal sebagai Z, waktu
, sebelumnya dikenal sebagai Greenwich Mean Time. Mereka selalu dikonversi ke UTC setelah disimpan, dan selalu dikonversi kembali setelah diambil.
Fungsi bawaan
untuk mendapatkan tanggal dan waktu saat ini (NOW() dan teman-teman) sensitif terhadap zona waktu . Mereka akan menghasilkan nilai dalam waktu setempat. Pengecualiannya adalah tiga fungsi yang dimulai dengan UTC_ yang menghasilkan nilai dalam waktu UTC.
Banyak aplikasi MySQL multi-zona waktu menggunakan disiplin operasional berikut:
- Tanyakan zona waktu preferensi pengguna kepada setiap pengguna, atau cari tahu dari beberapa data pribadi lain tentang pengguna. (Telepon memiliki informasi ini yang disediakan ke dalamnya dari jaringan.) Simpan itu sebagai ramah zona info deskriptor zona waktu ('America/New_York', 'Canada/Mountain', 'Europe/Wina', dll) atas nama pengguna.
- Saat membuat sesi MySQL atas nama pengguna, setel zona waktu pengguna dengan
set time_zonepermintaan seperti yang ditunjukkan di atas. Anda harus melakukannya tepat setelahconnectoperasi. - Simpan tanggal dan waktu untuk pengguna ke dalam
TIMESTAMPtipe data. Mereka akan dikonversi ke UTC saat disimpan. - Ambil sesuai kebutuhan. Mereka akan dikonversi kembali ke waktu lokal.
Idenya adalah bahwa zona waktu pengguna Anda adalah bagian dari konteksnya. Ini berfungsi dengan baik, karena jika pengguna A di Vancouver dan pengguna B di Halifax, dan untuk beberapa alasan pengguna B melihat data waktu pengguna A, data tersebut akan ditampilkan ke B dalam waktu Atlantik kurang lebih secara otomatis.
Ini juga bagus karena berurusan secara transparan dengan perubahan global dari siang hari ke waktu standar. Stempel waktu dari musim panas lalu akan ditampilkan dalam waktu setempat musim panas lalu.
Banyak manajer server untuk penggunaan global mengatur waktu server sistem mereka, atau zona waktu default MySQL mereka, ke UTC. (Milikmu tidak.)
Cara lain untuk menangani semua ini adalah cara Anda memulai. Pilih zona waktu dan simpan stempel waktu Anda sehubungan dengan zona waktu tersebut. Lebih baik jika Anda memilih zona waktu yang tidak bergantian antara siang hari dan waktu standar dalam kasus itu. Kemudian, saat menyimpan waktu ke dalam database, konversikan secara eksplisit. Anda akan menyimpan waktu dari pengguna di Ottawa dengan melakukan sesuatu seperti ini.
INSERT INTO tbl (appt) VALUES ( 'whatever-time' - INTERVAL 120 MINUTE)
dan Anda akan mendapatkan nilai dengan cara yang sama. Ini rawan kesalahan tetapi Anda dapat membuatnya bekerja.
Terakhir, Anda dapat melakukan konversi sendiri. Jika Anda ingin mengetahui berapa menit offset antara beberapa zona waktu arbitrer dan UTC, coba dua kueri ini.
set time_zone = 'Canada/Atlantic';
select timestampdiff(minute, utc_timestamp(), now());
Pada saat ini tahun yang memberikan kembali -240, yaitu -4:00. Anda perlu menggunakan menit daripada jam karena offset zona waktu setengah jam atau seperempat jam di beberapa negara.
Akhirnya, hati-hati. TIMESTAMP tipe data tidak mewakili waktu sebelum tahun 1970. Dan, pada instans MariaDB 10.0 saya, data tersebut tampak seperti neraka dalam ember tepat setelah 2038-01-19T03:14:07 UTC ketika waktu bergulir di luar 32 bit.
