Intervalo:
Há sempre a desvantagem óbvia:o intervalo que você pode armazenar é limitado de 1970 a 2038. Se você precisar armazenar datas fora desse intervalo, geralmente precisará usar outro formato. O caso mais comum que encontrei onde isso se aplica é a datas de nascimento.
Legibilidade:
Eu acho que a razão mais importante que as pessoas escolheram usar um dos tipos de data embutidos é que os dados são mais fáceis de interpretar. Você pode fazer uma seleção simples e entender os valores sem precisar formatar mais a resposta.
Índices:
Um bom motivo técnico para usar os tipos de data é que ele permite consultas indexadas em alguns casos que os timestamps unix não permitem. Considere a seguinte consulta:
SELECT * FROM tbl WHERE year(mydate_field) = 2009;
Se mydate_field for de um tipo de data nativo e houver um índice no campo, essa consulta usará um índice, apesar da chamada de função. Esta é praticamente a única vez que o mysql pode otimizar chamadas de função em campos como este. A consulta correspondente em um campo de carimbo de data/hora não poderá usar índices:
SELECT * FROM tbl WHERE year(from_unixtime(mytimestamp_field)) = 2009;
Se você pensar um pouco sobre isso, há uma maneira de contornar isso, no entanto. Essa consulta faz a mesma coisa e vai ser capaz de usar otimizações de índice:
SELECT * FROM tbl WHERE mytimestamp_field > unix_timestamp("2009-01-01") AND mytimestamp_field < unix_timestamp("2010-01-01");
Cálculos:
Geralmente, armazeno datas como unix time, apesar das desvantagens. Isso não é realmente baseado em seus méritos, mas é porque eu estou acostumado com isso. Descobri que isso simplifica alguns cálculos, mas complica outros. Por exemplo, é muito difícil adicionar um mês a um timestamp unix, pois o número de segundos por mês varia. Isto é muito fácil usando a função mysql DATE_ADD(). No entanto, acho que na maioria dos casos isso simplifica os cálculos. Por exemplo, é bastante comum que você queira selecionar as postagens, digamos, dos últimos dois dias. Se o campo contiver um timestamp unix, isso pode ser feito facilmente simplesmente fazendo:
SELECT * FROM tbl WHERE mytimestamp_field > time() - 2*24*3600;
Provavelmente é uma questão de gosto, mas pessoalmente acho isso mais rápido e fácil do que ter que lembrar a sintaxe de uma função como DATE_SUB().
Fusos horários:
Os carimbos de data/hora do Unix não podem armazenar dados de fuso horário. Eu moro na Suécia, que tem um único fuso horário, então isso não é realmente um problema para mim. No entanto, pode ser uma grande dor se você mora em um país que abrange vários fusos horários.
