MySQL がタイムスタンプを使用するときにタイムゾーンの問題を無視できるのはなぜですか?

私はいつも、なぜMySQLデータベースのtimestampタイムゾーンの問題を無視できるのか疑問に思っていました。
私は業務でLaravelフレームワークを使用しており、組み込みのMigrationでもtimestamp型のフィールドを使用しているため、あまり気にしていません。

始める

現在のデータベースのタイムゾーンを表示する

mysql> "%time_zone%"のような変数を表示します。
+------------------+--------+
| 変数名 | 値 |
+------------------+--------+
| システムタイムゾーン | CST |
| タイムゾーン | +08:00 |
+------------------+--------+
セット2列（0.30秒）

テーブル構造を表示

mysql> desc timestamp_test;
+--------------+-----------+------+-----+---------+----------------+
| フィールド | タイプ | Null | キー | デフォルト | 追加 |
+--------------+-----------+------+-----+---------+----------------+
| id | int | NO | PRI | NULL | auto_increment |
| created_time | datetime | YES | | NULL | |
| created_at | タイムスタンプ | YES | | NULL | |
+--------------+-----------+------+-----+---------+----------------+
3 列セット (0.26 秒)

データの挿入

mysql> timestamp_test(created_time, created_at) に値('2020-12-09 08:00:00', '2020-12-09 08:00:00') を挿入します。
クエリは正常、1 行が影響を受けました (0.22 秒)


mysql> timestamp_test から * を選択します。
+----+---------------------+---------------------+
| id | 作成日時 | 作成日時 |
+----+---------------------+---------------------+
| 1 | 2020-12-09 08:00:00 | 2020-12-09 08:00:00 |
+----+---------------------+---------------------+
セット内の1行（0.06秒）

今回は正しいようなので、タイムゾーンを変更して再度データを挿入してみます。

mysql> タイムゾーンを "+00:00" に設定します。
クエリは正常、影響を受けた行は 0 行 (0.03 秒)

mysql> timestamp_test(created_time, created_at) に値('2020-12-09 08:00:00', '2020-12-09 08:00:00') を挿入します。
クエリは正常、1 行が影響を受けました (0.03 秒)

mysql> タイムゾーンを "+08:00" に設定します。
クエリは正常、影響を受けた行は 0 行 (0.04 秒)

もう一度データを確認してください。挿入された 2 つのSQLは同じですが、クエリの結果は異なります。2 つのデータ間のcreated_atの違いは、まさにタイムゾーンの時間差です。

mysql> timestamp_test から * を選択します。
+----+---------------------+---------------------+
| id | 作成日時 | 作成日時 |
+----+---------------------+---------------------+
| 1 | 2020-12-09 08:00:00 | 2020-12-09 08:00:00 |
| 2 | 2020-12-09 08:00:00 | 2020-12-09 16:00:00 |
+----+---------------------+---------------------+
セットに2行（0.06秒）

実際に保存されたタイムスタンプを見てみましょう。次に、タイムゾーンを変更すると、フィールドの時間は変更されていますが、元のタイムスタンプのデータは変更されていないことがわかります。

mysql> timestamp_test から unix_timestamp(created_at) を * として選択します。
+----+---------------------+---------------------+----------------------------+
| id | created_time | created_at | unix_timestamp(created_at) |
+----+---------------------+---------------------+----------------------------+
| 1 | 2020-12-09 08:00:00 | 2020-12-09 08:00:00 | 1607472000 |
| 2 | 2020-12-09 08:00:00 | 2020-12-09 16:00:00 | 1607500800 |
+----+---------------------+---------------------+----------------------------+
セットに2行（0.06秒）

mysql> タイムゾーンを "+00:00" に設定します。
クエリは正常、影響を受けた行は 0 行 (0.09 秒)

mysql> "%time_zone%"のような変数を表示します。
+------------------+--------+
| 変数名 | 値 |
+------------------+--------+
| システムタイムゾーン | CST |
| タイムゾーン | +00:00 |
+------------------+--------+
セットに2行（0.08秒）

mysql> timestamp_test から unix_timestamp(created_at) を * として選択します。
+----+---------------------+---------------------+----------------------------+
| id | created_time | created_at | unix_timestamp(created_at) |
+----+---------------------+---------------------+----------------------------+
| 1 | 2020-12-09 08:00:00 | 2020-12-09 00:00:00 | 1607472000 |
| 2 | 2020-12-09 08:00:00 | 2020-12-09 08:00:00 | 1607500800 |
+----+---------------------+---------------------+----------------------------+
セット2行（0.18秒）

MySQLこれらすべてを暗黙的に変換するので、タイムゾーンの問題を心配する必要はありません。

データベースは実際には UTC タイムスタンプを保存します。書き込み時には、まずセッションタイムゾーンに従って UTC 時間に変換されます。読み取り時には、セッションタイムゾーンに従って現在のタイムゾーンに変換されます。これらの変換は透過的です。

2020-12-09 08:00:00データを正の8分の1ゾーンに保存するとします。
このデータは第8ゾーンで取得されましたが、時刻はまだ2020-12-09 08:00:00
現時点では、ゼロタイムゾーンにサーバーがあり、 MySQLに接続し、現在の接続のタイムゾーンを+00:00に設定しています。次に、データベースレコードを確認すると、見つかったデータは2020-12-09 00:00:00で、ゼロタイムゾーンの時間に対応しています。このように、タイムゾーンの問題を考慮する必要はありません。

上記は、MySQL タイムスタンプがタイムゾーンの問題を無視できる理由の詳細です。タイムゾーンを無視する MySQL タイムスタンプの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。

以下もご興味があるかもしれません: