Rango:
Siempre existe la desventaja obvia:el rango que puede almacenar está limitado desde 1970 hasta 2038. Si necesita almacenar fechas fuera de este rango, generalmente necesitará usar otro formato. El caso más común que he encontrado donde esto se aplica es a las fechas de nacimiento.
Legible:
Creo que la razón más importante por la que las personas eligieron usar uno de los tipos de fecha incorporados es que los datos son más fáciles de interpretar. Puede hacer una selección simple y comprender los valores sin tener que formatear más la respuesta.
Índices:
Una buena razón técnica para usar los tipos de fecha es que permite consultas indexadas en algunos casos que las marcas de tiempo de Unix no permiten. Considere la siguiente consulta:
SELECT * FROM tbl WHERE year(mydate_field) = 2009;
Si mydate_field es de un tipo de fecha nativa y hay un índice en el campo, esta consulta en realidad usará un índice, a pesar de la llamada a la función. Esta es prácticamente la única vez que mysql puede optimizar las llamadas a funciones en campos como este. La consulta correspondiente en un campo de marca de tiempo no podrá usar índices:
SELECT * FROM tbl WHERE year(from_unixtime(mytimestamp_field)) = 2009;
Sin embargo, si lo piensas un poco, hay una forma de evitarlo. Esta consulta hace lo mismo y lo hará ser capaz de utilizar optimizaciones de índice:
SELECT * FROM tbl WHERE mytimestamp_field > unix_timestamp("2009-01-01") AND mytimestamp_field < unix_timestamp("2010-01-01");
Cálculos:
Generalmente, almaceno fechas como hora de Unix, a pesar de las desventajas. Esto no se basa realmente en sus méritos, sino porque estoy acostumbrado. Descubrí que esto simplifica algunos cálculos, pero complica otros. Por ejemplo, es muy difícil agregar un mes a una marca de tiempo de Unix ya que la cantidad de segundos por mes varía. Esto es muy fácil usando la función mysql DATE_ADD(). Sin embargo, creo que en la mayoría de los casos simplifica los cálculos. Por ejemplo, es bastante común que desee seleccionar las publicaciones de, digamos, los últimos dos días. Si el campo contiene una marca de tiempo de Unix, esto se puede hacer fácilmente simplemente haciendo:
SELECT * FROM tbl WHERE mytimestamp_field > time() - 2*24*3600;
Probablemente sea cuestión de gustos, pero personalmente encuentro esto más rápido y fácil que tener que recordar la sintaxis de una función como DATE_SUB().
Zonas horarias:
Las marcas de tiempo de Unix no pueden almacenar datos de zona horaria. Vivo en Suecia, que tiene una sola zona horaria, por lo que esto no es realmente un problema para mí. Sin embargo, puede ser un gran dolor si vives en un país que abarca varias zonas horarias.
