MySQLに日付を保存するときにタイムゾーンを操作する
登録済みの基本的なサイトがあります。他のすべてのデータとともに、MySQLに登録日を保存します。私が米国またはカナダにいて、2017-03-07 (Y-d-m)に登録した場合、MySQLでは2017-04-07 10時間の時差があるため。私のサイトで日付を表示したいのであれば、それは将来起こっていることを示しています。私は何をしなければなりませんか？
デフォルトのUTC_DATEを設定するだけではなく、もう少し深く掘り下げる必要があると思います。 UTC_DATEのデフォルトは問題の解決に役立ちますが、アプリケーションでタイムゾーンを操作するというより大きな問題には対応していません。
タイムゾーンが通常処理される方法は3つあります。
- そうではありません。すべてのユーザーがサーバーと同じタイムゾーンにいると想定します。ほとんどの場合、これはひどいアプローチです。選択したタイムゾーンアプローチの問題は、事後に変更することがほぼ不可能であり、このように始めた人が後で変更する必要がある可能性が高いことです。その上、サーバーのタイムゾーンが変更された場合（不注意またはそれ以外の場合）、深刻な副作用が発生し、システム全体がクラッシュする可能性があります。
- ユーザーは自分のアカウントのタイムゾーンを指定し、UTCを保存します。この場合、ユーザーはプロファイルを作成したら、自分のアカウントに使用するタイムゾーンを選択します。この設定は、そのユーザーアカウントでデータベースに保存されます。一方、データベースに格納されるすべての日付は、標準のタイムゾーンを使用して格納されます（当然、これはUTCです）。ここで、ユーザーからの日付を保存する前に、ユーザーのタイムゾーンを考慮に入れてオフセットします（日付がUTCで保存されるようにします）。日付を表示する前に、タイムゾーンオフセットを使用してプレゼンテーションレイヤーを調整します。このアプローチは＃1よりもはるかに優れていますが、いくつかの欠点があります。これの欠点は、＃1の場合のように、アプリケーションが使用できなくなる可能性があるタイプではないことに注意してください。
- クライアント/エージェントのタイムゾーンを使用し、UTCを保存最新のWebクライアントは、現在のタイムゾーンをサーバーに提示できる必要があります。すべてのサーバー側の日付を標準タイムゾーン（UTC）で格納することを計画し、サーバーに渡されるすべての日付がクライアントによってUTCにオフセットされることを計画します。これにより、サーバーはすべてのタイムゾーンの扱いから完全に解放されます（本当に便利です）が、フロントエンドの負担が大きくなり、すべてをローカルからUTCに変換していることを確認します（場合によっては痛みを伴いますが、それでもクライアントの責任です）。 。）。同様に、サーバーはUTC日付のみを提供し、クライアントは表示目的でそれらを現地時間に変換する必要があります。私の考えでは、これがタイムゾーンを処理する唯一の正しい方法です。
覚えておくべき重要なことは、一度アプローチを選択すると、後でそれを変更することは非常に難しいことです！賢明に選択してください:)
格納するテーブルを作成するだけです UTC_DATE （[〜＃〜] default [として〜＃〜]値。
CREATE MyTable
...
MyColumn DATE DEFAULT UTC_DATE
...
今後同様の問題が発生する場合は、 プログラミングにおける時間の非常に徹底的な説明 を参照してください。それは私を大いに助けました。
時間を処理する方法の1つは、
ストア：
JavaScriptライブラリまたはその他のフロントエンドを使用して現地時間を取得します。
JSフロントエンドでUTC Unixタイムスタンプに変換します。
それをUTCとしてバックエンドに渡し、UTCとしてデータベースに格納します。
および取得：
UTCとしてデータベースから取得し、
バックエンドを介してUTCとしてJavaScriptに渡し、
JS（フロントエンド）に現地時間に変換させます。
要約すると、常にバックエンドとデータベースでは時間をUTCとして扱います。フロントエンドだけがユーザーのタイムゾーンを推測できるため、フロントエンドで時間をローカルに変換します。ほとんどの場合、それはかなり適切に推測されます。タイムゾーン、DST、旅行ユーザー、VPNなどの複雑さのため、100％フェイルプルーフのソリューションは存在しないようです。