-2

データベースに日付を保存するときは、 time（）関数の番号を使用して日付を保存する方が正確であると常に信じていましたが、 2013-02-01のような日付を保存する人もいます。

どちらがお勧めですか？それとも、どちらを使うべきか、別の機会がありますか？

4

3 に答える 3

0

次の理由DATEではなく、日付を保存します。INT

  • より読みやすい
  • まだデートです！

とにかくそれはまだあなたのオプションです、これを考慮してください、

SELECT UNIX_TIMESTAMP(CURDATE()), CURDATE()

結果になります

UNIX_TIMESTAMP(CURDATE())   CURDATE()
1359676800                  2013-02-01 00:00:00
于 2013-02-01T13:57:24.473 に答える
0

ISO 8601 で標準化することは保守的であり、time_t UNIX エポックとの間で変換するよりもはるかに簡単です。

翌日の開始は時差の影響を受ける可能性があるため、タイム ゾーンに問題が生じる可能性があります。サマータイム中は、一日の始まりが影響を受ける可能性があります。time_t を使用すると、これらの問題が明確になる可能性がありますが、意図した効果に対して time_t を正しく変換しなかったために、問題が発生する可能性もあります。

UNIX 時間エポックには時間コンポーネントがあるため、time_t 値を送信し、データベースにそれを日付に変換させると、これが問題になる可能性があります。データベースは、予期しない方法で翻訳する可能性があります。ただし、日付を送信すると、データベースはあなたの言葉に従ってその日付を保存し (日付が含まれていると考えられるタイムゾーンに関係なく)、その正確な日付を返します。

SQL に含まれる日付値を取得する方法によっては、このような変換の問題が発生する可能性があります。ただし、これはコードの問題であり、データベースが送信した値を変換または変更していないと予想できます。

日付は読み取り可能であり、日付であり、さまざまな状況で問題が発生したとしても、time_t よりも問題がないため、日付として入力することに固執します。

于 2013-02-01T14:02:32.210 に答える
0

常に日付のテキスト表現として保存しますYYYY-MM-DD。人間が読みやすく、Unix タイムスタンプ整数の制限に制限されません (整数を使用すると、前方または後方にしか移動できません)。

于 2013-02-01T14:00:17.357 に答える