ユーザ単位でタイムゾーン間で翻訳するWebアプリケーションが必要な場合は、すべての日付/時刻フィールドでTIMESTAMPをボード全体で使用しないでください。 TIMESTAMP値がUTCに格納され、取得時に接続のタイムゾーンに変換されているとします。なぜMySQLのTIMESTAMPを全面的に使用しないのですか？
私はIRCでこの質問をし、MySQLのドキュメントを読んだり、広範囲にGoogleを検索したりして、私の同僚に尋ねましたが、TIMESTAMPを使用しない魅力的な理由はまだありません。
注：TIMESTAMPには1970年から2038年の限定された範囲があります。それは私の場合に問題になることはありません。また、MySQLでPHPを使用しています。
DATETIMEは、データで使用する任意の日時です。
TIMESTAMPは、時刻を自動的に更新する場合に使用します。行が挿入/更新されたときを知りたい場合は、TIMESTAMPを使用します。
また、TIMESTAMPだけ保存 UTCであることに留意してください - それはクエリの一部として返送される前には、サーバーのローカルタイムゾーンに変換されます。
あなたの場合は、DATETIMEを使用する方がよいでしょう。 UTCについて心配しているのなら、それは問題ありません。現地時間を使用するのではなく、UTCで日付を作成してください。 UTC_TIMESTAMPを使用してください。
私はあなたの答えはここにあると思う：
私はTIMESTAMPは、1970年の限られた範囲がある理解 - 2038; 私の場合は問題になることはありません。
私はそれがデータベース・スキーマに来る場合は特に、プロジェクトの寿命について注意づくりの前提になります。データベースは、それらを使用していたアプリケーションがなくなってしまった後も、その場にとどまって使用される傾向があります。
確かに、MySQLは2038年問題のパッチをリリースしたでしょう - 特に大多数のコンピュータが64ビット版になると考えていますか？ –
おそらく彼らは成功するだろうが、成功した開発者であることの一部は、最善を尽くすことを期待するのではなく、最悪のことを計画することである。 –
25年後にテーブルを変更する方法を考え出すと、あなたの時間を費やす価値のあるもののリストに表示されます。あなたは、私たちのほとんどよりはるかに優れた形になっています。 – DougW
ランダルホの答えは多くの事実で間違っています！
タイムスタンプは、作成または更新時に自動的に更新する必要はありません。
また、タイムスタンプは、クライアントのローカルタイムではなく、クライアントのローカルタイムに変換されます。
datetimeのMySQLドキュメントを見てください。
これは本当にコメントであり、答えではありません。もう少し担当者がいれば、[あなたはコメントを投稿できる]（http://stackoverflow.com/privileges/comment）。 – Emil
レスポンスありがとうございます、なぜ私はDATETIMEを使用する方が良いのか分かりません。PHPの日付関数を使用している場所であれば、データベースマネージャがいつでもどこでも自分のコードベース全体に100を超える変換を行わなければならないと考えていますこの仕事は私のためです。 –
とにかくその日付の変換を行う必要があります。 TIMESTAMPは変換されたローカルサーバー時刻に戻ります。これはユーザーのタイムゾーンではありません。 UTCで日付を保存し、UIレベルのユーザーのタイムゾーンに変換する必要があります。 – Randolpho
ユーザのセッション内でデータベース接続が行われるたびに、「SET time_zone = 'users timezone'」を実行するとどうなりますか？それはあなたの心の中で良い解決策になりますか？ –