Вместо това можем да направим това:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
FROM_UNIXTIME функцията е ограничена от допустимия диапазон за TIMESTAMP тип данни, който е стандартният 32-битов неподписан INT диапазон от 1970-01-01 до 2038-01-нещо. Друг софтуер е актуализиран, за да поддържа 64-битови подписани цели числа, но MySQL все още не предоставя тази функционалност (поне не в 5.1.x).
Обходното решение в MySQL е избягване на използването на TIMESTAMP тип данни и използване на DATETIME вместо тип данни, когато имаме нужда от по-голям диапазон (напр. дати преди 1 януари 1970 г.).
Можем да използваме DATE_ADD функция за изваждане на секунди от 1 януари 1970 г., както следва:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
N.B. Вероятно ще трябва да вземете предвид "отместванията" на часовата зона спрямо UTC при извършването на тези видове изчисления. MySQL ще интерпретира стойностите на DATETIME като посочени в time_zone настройка на текущата сесия на MySQL, а не UTC (time_zone = '+00:00' )
ПОСЛЕДВАНЕ:
В: Добре, означава, че ако изберем дати под '1970-01-01 00:00:00', тогава отрицателната стойност се записва в db, иначе би била положителна. нали така? – soft genic
А: Ъъъъъ, не. Ако изберете стойности за дата/дата и час преди 1 януари 1970 г., MySQL ще върне стойностите за DATE или DATETIME преди 1 януари 1970 г. Ако съхраните стойности за DATE или DATETIME преди 1 януари 1970 г., тогава MySQL ще съхрани стойността DATE или DATETIME преди 1 януари , 1970 г., в рамките на допустимия диапазон, поддържан от тези типове данни. (нещо като 0001-01-01 до 9999?)
Ако трябва да съхранявате наистина големи положителни и отрицателни цели числа в базата данни, вероятно ще ги съхранявате в колона, дефинирана като BIGINT .
Вътрешното представяне на колона DATE изисква 3-байта място за съхранение, а DATETIME изисква 8-байта съхранение (до MySQL версия 5.6.4. Вътрешното представяне и съхранение на стойностите DATE и DATETIME се промени в 5.6.4)
Така че не, MySQL не съхранява стойности за дати преди 1970 г. като "отрицателни цели числа".
Ако се замислите малко, MySQL е свободен да приложи какъвто пожелае механизъм за съхранение. (И всяка машина за съхранение е свободна да сериализира това представяне на диск, както пожелае.)
Защо 3 байта за дата?
Една от опциите, която MySQL има (и аз не твърдя, че това е начинът, по който се прави) може да бъде да раздели датата на компоненти за годината и деня.
Представянето на целочислени стойности в диапазона - изисква -
-
0 - 9999 -14 бита -
0 - 12 -4 бита -
0 - 31 -5 бита
Това са общо 23 бита, които се побират удобно в 3 байта. Това само демонстрира, че не е необходимо MySQL да представя стойностите за дата преди 1 януари 1970 г. като отрицателни цели числа, така че не трябва да правим предположението, че го прави. (Но наистина бихме били загрижени само за това ниво на детайлност, ако работихме върху машина за съхранение за MySQL.)
