整数またはその他の適切なタイプを使用して、データベース内の日付/時刻の値を表すことができます。ただし、いくつかの問題が発生します。
データベーステーブルを使用する現在および将来の（!!!）アプリケーション（Javaまたはその他）はすべて、データベースの整数と日付/時刻の値の間で変換する必要があります。
SQLクエリ、SQLストアドプロシージャ、またはSQLトリガーに関連する列が含まれている場合は、変換を行う必要がある場合があります。それはそれらをより複雑にします/正しくするのを難しくします。さらに、複雑さが増すと、クエリエンジンがクエリの実行速度が遅くなる可能性があります...クエリオプティマイザはユーザーが何をしているかを理解していないためです。
整数を使用して日付を表すと、日付列を含むテーブルに対してアドホックSQLクエリを実行するのが難しくなります。
編集
日付を整数で表すことによってスペースを節約するかどうかは、データベース固有です。IIRC、Oracleは、日付/時刻の値をプリミティブ整数として格納します。そして、まともなRDBMSでも、ストレージスペースとクエリ効率の両方で同じことができると思います。
日付/時刻の値を整数として保存しても、タイムゾーンの問題には対処できません。これは根本的に複雑な問題です。
- 場合によっては、日付または日付/時刻で絶対的な時点を表す必要があります。
- それ以外の場合は、何らかのイベントが発生した地理的な場所/タイムゾーンを基準にした時点を表す必要があります。
- それ以外の場合は、システムまたはユーザーの場所を基準にした時間を表します。
次に、粒度の問題があります。（わかりやすくするためにISO日付構文を使用）「1999」は「1999-01-01」または「1999-01-01T00：00：00」と同じ意味ですか？そして、1秒未満の精度はどうですか？
重要なのは、単純なSQLの日付/時刻（または整数）表現ではこれらすべてを処理できないということです。私たちが目にするバグ/問題/問題の根本的な原因は、プログラマーが実装に近道を取り、（より重要なことに）思考がずさんなことです。
編集2
さまざまなデータベースとそれぞれのJDBCドライバーが日付リテラルとタイムゾーンに関する仮定を処理する方法の違いにより、多くの問題が依然として発生するという問題がまだあります。私はJDBCとSQL標準の専門家ではありませんが、根本的な問題は次のようです。
- データベースベンダーは、（たとえば）SQL-92で指定されている日時タイプを完全に実装していません。
- SQL標準では、日時リテラルに単一の構文を指定していませんが、データベースベンダー固有の構文を許可しています。
- SQL標準では、タイムゾーンをデフォルトにすることができますが、デフォルトを指定する（またはデフォルトにする）標準的な方法はありません。より多くのベンダー固有のソリューション。
- JDBC仕様では、アプリケーションがデフォルトのタイムゾーンを取得または設定したり、日時リテラル構文を選択したりする方法は提供されていません。
これらすべてが、Java開発者にとっての移植性と構成の問題の混乱につながります。ただし、Java/RDBMSアプリケーションの他の側面で発生する移植性と構成の問題よりも大幅に悪いとは思いません。そして、日時タイプを完全に捨てることによって、あなたは他の多くの問題に買い込むことになります。上記を参照。