UNIXタイムスタンプはタイムスタンプを保存する最良の方法ですか？
私は常にすべてにUNIXタイムスタンプを使用していますが、もっと良い方法があるかどうか疑問に思っています。
タイムスタンプを保存するために何を使用していますか？その理由は何ですか？
タイムスタンプを保存することを選択した場合でも、地域の解釈の問題と時間オフセットの問題を回避することが重要です。 Unixタイムスタンプは、地域に関係なく同じように解釈され、タイムゾーンに関係なく同じ時点から計算されます。これらは良いことです。
タイムスタンプを01/02/2008などのあいまいな文字列として格納することに注意してください。これは、ロケールに応じて、2008年1月2日または2008年2月1日として解釈される可能性があるためです。
時間/分/秒を格納する場合、「どの」時間/分/秒が指定されているかを知ることが重要です。これを行うには、タイムゾーン情報を含めます（UTCと見なされるため、Unixタイムスタンプには必要ありません）。
ただし、Unixタイムスタンプは特定の瞬間を一意に表すことができないことに注意してください。UTCにうるう秒がある場合、Unixタイムスタンプは変更されないため、23：59：60 UTCと翌日の00:00:00は同じになります。 Unix表現。したがって、1秒以上の解像度が本当に必要な場合は、別のフォーマットを検討してください。
Unixタイムスタンプよりも人間が読める形式で保存したい場合は、 ISO 8601 を検討してください。
わかりやすくする1つの手法は、日付をUTCとして保存し、ユーザーに日付を表示するときにタイムゾーンまたはDSTオフセットのみを適用することです。
ログファイルを保存している場合は、ピートの愛情を込めて、人間が読める形式にして字句的にソートできるようにしてください。
たとえば、2008-10-07 09:47:02。
2ビットUnixタイムスタンプは数年でオーバーフローします（2038年1月） なので、これは考慮事項になるかもしれません。通常、SQLではDATETIME形式を使用します。これは、YYYY-MM-DD HH：MM：SSであり、時刻は24時間制です。人生を楽にするために、同じ形式のファイルに出力しようとしています。
保存する必要がある時代と解像度は何ですか？マイクロ秒が必要な場合、または石器時代の日付time_tは最適ではない可能性があります。一般的なビジネスの目的にはかなり良いです（64ビットを想定）
タイムスタンプが何のために必要かによります。
UNIXタイムスタンプは、2008-12-31T23：59：59Zの1秒後の時間を表すことはできません。 '2009-01-01T09：00：00'-'2008-12-31T09：00：00'をUNIXタイムスタンプで実行すると、結果は正しくありません。これら2つの日付の間にはうるう秒があり、それらは分離されます86401秒（UNIXタイムスタンプからわかる86400ではない）。
それと他のレスポンダーが言ったこと以外、はい-unixタイムスタンプは行く方法です:)
タイムスタンプは、夏時間や現在の現地時間を考慮しないため、データベースには適していません。 MySQLでは、時刻として保存し、次に MySQL日付および時刻関数 を使用して必要な部分を取得するか、他の日付と比較することをお勧めします。
1秒未満の精度が必要な場合はtimevalスタイル（time_t +マイクロ秒）。それ以外の場合はtime_tのみ。 64ビット整数値を使用してtime_t * 1000000 + usecを格納でき、+ /-292,000年以上オーバーフロー防止できます。
UNIXタイムスタンプ32ビットの問題は、2038以降に将来の日付を入力するユーザーにとってかなり煩わしいようです。
MySQLのDATETIMEシーケンスを使用するか、日付をBIGINT（8）符号なし（最大：18千兆）またはFLOATとして保存して、大きな数値を入力できるようにします。次に、たとえば、32ビットシステムによって制限される整数としてのみパラメーターを許可するため、PHPのdate（）関数を使用できません。
私が見つけた解決策は、PHP 5.2.0関数を使用することです。 DateTime PHP solution です。
UNIX_TIMESTAMP形式を変更する必要はありません。タイムスタンプのMySQLストレージとして署名されていないBIGINT（8）がある限り。 32ビットシステムに制限されることはもうありません。