Heidisql: グリッドの日付値として間違ったタイムスタンプが表示される

ねえ@mpaland 、あなたのMariaDBは正しいタイムゾーンのヨーロッパ/ベルリンで実行されていますか？
私は多くの変換を処理しません、タイムスタンプはUTCに書き込みますね？ そしてMySQLはあなたのタイムゾーンに変換しますか？

私は再現しようとしましたが、私が持っているサーバーにはタイムゾーンがインストールされていません:(

@lukinhaspmサーバーの問題ではなく、HeidiSQLの正しいタイムスタンプ表現の問題です。 UNIX TIMESTAMPは、常に1970-01-01 00：00：00UTCから秒単位であることが意図されています。

このようなタイムスタンプは、厳密にUTCで表示できます。これは問題ありませんが、特定の（ほとんどの場合は独自の）タイムゾーンで表示できます。 それをやって、タイムスタンプの日付ではなく、実際の日付で有効なタイムゾーンを必要とします。
HeidiSQLが実際の日付を取っているようです。 私はまだそのコードを調べていないので、それは単なる推測です。

@mpaland私は理解し、同意します！

これをもう少し調べました。 残念ながら、解決策は簡単ではないようです。
問題は、世界中の複雑なDST（夏時間）ルールであり、さらに悪いことに、それらの継続的に変化する非一定の形式です。
特定のエポックタイムスタンプに対して現地時間のDSTを修正するには、タイムスタンプ時にローカルに適用された正確なDSTルールを知る必要があります。
変換ライブラリは、過去の任意のポイントのオフセットを計算するために、すべての国で何年にもわたってすべてのDSTルールの変更を追跡する必要があります。
Windowsはこの問題を完全に無視し、変換時に常に_actual_DSTルールに従って変換します。
それを正しく行うには、ネット上で非常に高度なタイムゾーン/ DSTライブラリの1つを使用する必要があります。

タイムスタンプの作成時に適用されるDSTルールを知る必要があることについて@mpalandが述べたことのほとんどは技術的には正しいですが（たとえば、夏時間を削除すると、アクティブな間に記録されたすべての瞬間が相対的な非夏時間に「シフト」します時間の節約）、現在のDSTルールを使用して、タイムスタンプの時間を適切に表示することは可能です。

1584975600と1585576800はどちらもヨーロッパ/マドリードで16:00ですが、heidisqlはそれらの1つを誤って表します（夏時間であるかどうかによって異なります）

結果の時間が夏時間であるかどうかを確認し、正しいオフセットを適用するだけで、大きな手間をかけずにこれらのケースを正しく表示できる可能性があります。

完璧なソリューションではありませんが、おそらくほとんどのユースケースをカバーしており、エッジケースは簡単に見つけられるでしょう。とにかく、エンドユーザーの信頼できるディスプレイよりも、開発者が問題を確認するための小さな助けになります。