範囲：
常に明らかな欠点があります。保存できる範囲は1970年から2038年までに制限されています。この範囲外の日付を保存する必要がある場合は、通常、別の形式を使用する必要があります。これが当てはまる最も一般的なケースは、生年月日です。
読みやすさ：
組み込みの日付タイプの1つを使用することを選択した最も重要な理由は、データの解釈が容易であるためだと思います。簡単な選択を行うことができ、応答をさらにフォーマットしなくても値を理解できます。
インデックス：
日付タイプを使用する技術的な理由は、UNIXタイムスタンプではできない場合があるインデックス付きクエリを許可することです。次のクエリについて考えてみます。
SELECT * FROM tbl WHERE year(mydate_field) = 2009;
mydate_fieldがネイティブの日付タイプであり、フィールドにインデックスがある場合、関数呼び出しにもかかわらず、このクエリは実際にはインデックスを使用します。これは、mysqlがこのようなフィールドでの関数呼び出しを最適化できる唯一の時間です。タイムスタンプフィールドの対応するクエリは、インデックスを使用できません：
SELECT * FROM tbl WHERE year(from_unixtime(mytimestamp_field)) = 2009;
少し考えてみると、それを回避する方法があります。このクエリは同じことを行い、 インデックスの最適化を使用できるようにする：
SELECT * FROM tbl WHERE mytimestamp_field > unix_timestamp("2009-01-01") AND mytimestamp_field < unix_timestamp("2010-01-01");
計算：
不利な点はありますが、通常、日付はUNIX時間として保存します。これは実際にはメリットに基づくものではなく、慣れているからです。これにより、一部の計算が簡略化されますが、他の計算は複雑になることがわかりました。たとえば、1か月あたりの秒数はさまざまであるため、UNIXタイムスタンプに1か月を追加することは非常に困難です。これは、mysql DATE_ADD（）関数を使用すると非常に簡単です。ただし、ほとんどの場合、実際には計算が簡単になると思います。たとえば、過去2日間の投稿を選択することはよくあることです。フィールドにUNIXタイムスタンプが含まれている場合、これは次のようにするだけで簡単に実行できます。
SELECT * FROM tbl WHERE mytimestamp_field > time() - 2*24*3600;
おそらく好みの問題ですが、個人的には、DATE_SUB（）などの関数の構文を理解するよりも速くて簡単だと思います。
タイムゾーン：
Unixタイムスタンプはタイムゾーンデータを保存できません。私は単一のタイムゾーンを持つスウェーデンに住んでいるので、これは私にとって実際には問題ではありません。ただし、複数のタイムゾーンにまたがる国に住んでいる場合は、大きな問題になる可能性があります。