この時間診断クエリをMySQLサーバーで実行しました。
select @@time_zone, now(), utc_timestamp()
サーバーマシンのシステムタイムゾーン設定が「カナダ/山」であり、MySQLサーバーソフトウェアに独自のタイムゾーン設定がないことは、現地時間とutc時間から明らかです。
テーブルを手に取り、近くのタイムゾーンで変更せずにサーバーに移動すると、ソフトウェアをいつでも更新してコマンドを発行できます
set time_zone = 'Canada/Mountain';
ソフトウェアから接続した直後。これにより、新しいMySQL接続が現在のMySQL接続と同じようにタイムゾーンで動作するようになります。 MySQLサーバーを所有している場合は、このページの指示に従ってデフォルトのタイムゾーンを設定できます。 http://dev.mysql.com/doc /refman/5.5/en/time-zone-support.html
さて、これが時間データ型についての話です。 DATE 、TIME 、およびDATETIME すべてタイムゾーンに依存しない 。日付/時刻の値を保存すると、タイムゾーン設定を変更しても同じ値に戻ります。
TIMESTAMP データ型はタイムゾーンに依存します 。これらのデータ項目は、常に UTC、別名Z、時間
に保存されます。 、以前はグリニッジ標準時として知られていました。保存時に常にUTCに変換され、取得時に常に元に戻されます。
組み込み関数
現在の日付と時刻を取得するため（NOW() および友人）はタイムゾーンに依存します 。それらは現地時間で値を生成します。例外は、UTC_で始まる3つの関数です。 UTC時間で値を生成します。
多くのMySQLマルチタイムゾーンアプリケーションは、次の運用規律を使用しています。
- 各ユーザーにユーザー設定のタイムゾーンを尋ねるか、ユーザーに関する他の個人データからそれを把握します。 （電話には、ネットワークからこの情報がプロビジョニングされています。）zoneinfo-friendly> ユーザーに代わってタイムゾーン記述子（「アメリカ/ニューヨーク」、「カナダ/山」、「ヨーロッパ/ウィーン」など）。
- ユーザーに代わってMySQLセッションを確立したら、
set time_zoneを使用してユーザーのタイムゾーンを設定します。 上記のようなクエリ。connectの直後にこれを行う必要があります 操作。 - ユーザーの日付と時刻を
TIMESTAMPに保存します データ型。保存時にUTCに変換されます。 - 必要に応じてそれらを取得します。現地時間に戻されます。
アイデアは、ユーザーのタイムゾーンが彼女のコンテキストの一部であるということです。ユーザーAがバンクーバーにいてユーザーBがハリファックスにいて、何らかの理由でユーザーBがユーザーAの時間データを表示すると、大西洋時間にほぼ自動的にBに表示されるため、これはうまく機能します。
また、日光から標準時間への変化という世界的な変動に透過的に対処するため、これも優れています。昨年の夏のタイムスタンプは、昨年の夏の現地時間で表示されます。
グローバルに使用するサーバーの多くのマネージャーは、システムサーバーの時刻またはMySQLのデフォルトのタイムゾーンをUTCに設定します。 （あなたはそうではありません。）
これらすべてを処理する別の方法は、開始した方法です。タイムゾーンを選択し、そのタイムゾーンに関するタイムスタンプを保存します。その場合、日中と標準時が交互にならないタイムゾーンを選択するのが最善です。次に、時間をデータベースに保存するときに、明示的に変換します。このようなことを行うことで、オタワのユーザーからの時間を保存します。
INSERT INTO tbl (appt) VALUES ( 'whatever-time' - INTERVAL 120 MINUTE)
同じ方法で値を取得できます。これはエラーが発生しやすいですが、機能させることができます。
最後に、自分で変換を行うことができます。任意のタイムゾーンとUTCの間に何分のオフセットがあるかを知りたい場合は、これら2つのクエリを試してください。
set time_zone = 'Canada/Atlantic';
select timestampdiff(minute, utc_timestamp(), now());
今年のこの時期には、-240、つまり-4：00が返されます。一部の国では30分または15分タイムゾーンのオフセットがあるため、時間ではなく分を使用する必要があります。
最後に、気を付けてください。 TIMESTAMP データ型は1970年以前の時刻を表していません。また、私のMariaDB 10.0インスタンスでは、時刻が32ビットからロールオーバーした2038-01-19T03：14：07UTCの直後にバケット内で地獄に行くように見えます。