Plage :
Il y a toujours un inconvénient évident :la plage que vous pouvez stocker est limitée de 1970 à 2038. Si vous devez stocker des dates en dehors de cette plage, vous devrez généralement utiliser un autre format. Le cas le plus courant que j'ai trouvé où cela s'applique est celui des dates de naissance.
Lisibilité :
Je pense que la raison la plus importante pour laquelle les gens ont choisi d'utiliser l'un des types de date intégrés est que les données sont plus faciles à interpréter. Vous pouvez effectuer une simple sélection et comprendre les valeurs sans avoir à formater davantage la réponse.
Index :
Une bonne raison technique d'utiliser les types de date est qu'ils permettent une requête indexée dans certains cas, ce que les horodatages Unix ne permettent pas. Considérez la requête suivante :
SELECT * FROM tbl WHERE year(mydate_field) = 2009;
Si mydate_field est d'un type de date natif et qu'il existe un index sur le champ, cette requête utilisera en fait un index, malgré l'appel de la fonction. C'est à peu près la seule fois où mysql peut optimiser les appels de fonction sur des champs comme celui-ci. La requête correspondante sur un champ timestamp ne pourra pas utiliser d'index :
SELECT * FROM tbl WHERE year(from_unixtime(mytimestamp_field)) = 2009;
Si vous y réfléchissez un peu, il y a cependant un moyen de contourner le problème. Cette requête fait la même chose, et va pouvoir utiliser les optimisations d'index :
SELECT * FROM tbl WHERE mytimestamp_field > unix_timestamp("2009-01-01") AND mytimestamp_field < unix_timestamp("2010-01-01");
Calculs :
Généralement, je stocke les dates en temps Unix, malgré les inconvénients. Ce n'est pas vraiment basé sur ses mérites, mais plutôt parce que j'y suis habitué. J'ai trouvé que cela simplifie certains calculs, mais en complique d'autres. Par exemple, il est très difficile d'ajouter un mois à un horodatage unix puisque le nombre de secondes par mois varie. C'est très facile en utilisant la fonction mysql DATE_ADD(). Cependant, je pense que dans la plupart des cas, cela simplifie en fait les calculs. Par exemple, il est assez courant que vous souhaitiez sélectionner les messages des deux derniers jours, par exemple. Si le champ contient un horodatage unix, cela peut être fait facilement en faisant simplement :
SELECT * FROM tbl WHERE mytimestamp_field > time() - 2*24*3600;
C'est probablement une question de goût, mais personnellement, je trouve cela plus rapide et plus facile que de devoir se souvenir de la syntaxe d'une fonction telle que DATE_SUB().
Fuseaux horaires :
Les horodatages Unix ne peuvent pas stocker les données de fuseau horaire. Je vis en Suède qui a un seul fuseau horaire, donc ce n'est pas vraiment un problème pour moi. Cependant, cela peut être très pénible si vous vivez dans un pays qui s'étend sur plusieurs fuseaux horaires.
