Heidisql: Tampilan stempel waktu salah sebagai nilai tanggal di kisi

hey @mpaland , MariaDB Anda berjalan dengan zona waktu yang benar Eropa/Berlin?
Saya tidak menangani banyak konversi, stempel waktu menulis ke UTC, bukan? dan MySQL mengonversi ke zona waktu Anda?

Saya mencoba mereproduksi tetapi di server yang saya miliki tanpa zona waktu yang diinstal :(

@lukinhaspm ini bukan masalah server, ini hanya pertanyaan tentang representasi cap waktu yang benar di HeidiSQL. UNIX TIMESTAMP selalu dimaksudkan dalam hitungan detik setelah 1970-01-01 00:00:00 UTC.

Anda dapat menyajikan stempel waktu seperti itu secara ketat di UTC, yang baik-baik saja, atau dalam zona waktu tertentu (kebanyakan milik sendiri). Melakukan itu, memerlukan zona waktu yang valid pada tanggal stempel waktu, bukan pada tanggal sebenarnya.
Tampaknya HeidiSQL mengambil tanggal sebenarnya. Saya belum melihat kodenya, jadi itu hanya spekulasi.

@mpaland Saya mengerti dan setuju!

Saya menyelidiki ini sedikit lebih jauh. Sayangnya solusinya sepertinya tidak mudah.
Masalahnya adalah aturan DST (waktu musim panas) yang rumit di seluruh dunia dan bahkan lebih buruk lagi, bentuknya yang terus berubah dan tidak konstan.
Untuk mendapatkan koreksi DST waktu lokal untuk stempel waktu epoch tertentu, perlu diketahui aturan DST yang tepat yang diterapkan secara lokal pada waktu stempel waktu.
Pustaka konversi perlu melacak semua perubahan aturan DST di setiap negara selama bertahun-tahun untuk menghitung offset untuk titik mana pun di masa lalu.
Windows sepenuhnya mengabaikan masalah ini dan selalu mengonversi sesuai dengan aturan _actual_ DST pada saat konversi.
Untuk melakukannya dengan benar, perlu menggunakan salah satu perpustakaan zona waktu/DST yang sangat canggih di internet.

Meskipun sebagian besar dari apa yang @mpaland telah nyatakan tentang

1584975600 dan 1585576800 keduanya 16:00 di Eropa/Madrid, tetapi heidisql salah mewakili salah satunya (tergantung apakah kita menggunakan waktu musim panas atau tidak)

Dimungkinkan untuk menampilkan kasing ini dengan benar tanpa menjadi masalah besar dengan hanya memeriksa apakah waktu yang dihasilkan harus pada waktu musim panas atau tidak dan menerapkan offset yang benar.

Meskipun ini bukan solusi yang sempurna, saya akan mengatakan itu mungkin mencakup sebagian besar kasus penggunaan, dan kasus tepi mungkin akan mudah terlihat, ini lebih merupakan bantuan kecil bagi para pengembang untuk memverifikasi sesuatu yang baik daripada tampilan yang dapat diandalkan pengguna akhir.