Обхват:
Винаги има очевидният недостатък:диапазонът, който можете да съхранявате, е ограничен от 1970 до 2038 г. Ако трябва да съхранявате дати извън този диапазон, обикновено ще трябва да използвате друг формат. Най-често срещаният случай, в който това се отнася, е за рождени дати.
Четимост:
Мисля, че най-важната причина хората да изберат да използват един от вградените типове дата е, че данните са по-лесни за интерпретиране. Можете да направите прост избор и да разберете стойностите, без да се налага допълнително да форматирате отговора.
Индекси:
Добра техническа причина за използване на типовете дата е, че позволява индексирана заявка в някои случаи, които нямат времеви марки в 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 време, въпреки недостатъците. Това всъщност не се основава на неговите достойнства, а по-скоро защото съм свикнал с него. Открих, че това опростява някои изчисления, но усложнява други. Например, много е трудно да добавите месец към времеви печат на unix, тъй като броят на секундите на месец варира. Това е много лесно с помощта на функцията mysql DATE_ADD(). Въпреки това мисля, че в повечето случаи това всъщност опростява изчисленията. Например, доста често е да искате да изберете публикациите от, да речем, последните два дни. Ако полето съдържа unix timestamp, това може да стане лесно, като просто направите:
SELECT * FROM tbl WHERE mytimestamp_field > time() - 2*24*3600;
Вероятно е въпрос на вкус, но аз лично намирам това по-бързо и по-лесно, отколкото да се налага да запомня синтаксиса на функция като DATE_SUB().
Часови зони:
Unix timestamps не могат да съхраняват данни за часовата зона. Живея в Швеция, която има една часова зона, така че това всъщност не е проблем за мен. Това обаче може да бъде голяма болка, ако живеете в държава, която обхваща няколко часови зони.
