Zamiast tego możemy to zrobić:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
FROM_UNIXTIME funkcja jest ograniczona dozwolonym zakresem dla TIMESTAMP datatype, który jest standardowym 32-bitowym zakresem unsigned int od 1970-01-01 do 2038-01-coś. Inne oprogramowanie zostało zaktualizowane do obsługi 64-bitowych liczb całkowitych ze znakiem, ale MySQL nie zapewnia jeszcze tej funkcji (przynajmniej nie w wersji 5.1.x).
Rozwiązaniem w MySQL jest unikanie używania TIMESTAMP typ danych i użycie DATETIME zamiast tego typu danych, gdy potrzebujemy większego zakresu (np. daty przed 1 stycznia 1970 r.).
Możemy użyć DATE_ADD funkcja odejmowania sekund od 1 stycznia 1970, tak:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
Uwaga Prawdopodobnie będziesz musiał uwzględnić „przesunięcia” strefy czasowej od czasu UTC podczas wykonywania tego typu obliczeń. MySQL zinterpretuje wartości DATETIME jako określone w time_zone ustawienie bieżącej sesji MySQL, a nie UTC (time_zone = '+00:00' )
KONTYNUACJA:
P: Dobra, oznacza to, że jeśli wybierzemy daty poniżej „1970-01-01 00:00:00”, to wartość ujemna zostanie zapisana w bazie danych, w przeciwnym razie byłaby dodatnia. Dobrze? – miękki gen
O: Nie. Jeśli wybierzesz wartości daty/daty i godziny przed 1 stycznia 1970, MySQL zwróci wartości DATE lub DATETIME przed 1 stycznia 1970. Jeśli zapiszesz wartości DATE lub DATETIME przed 1 stycznia 1970, MySQL zwróci wartości DATE lub DATETIME przed 1 stycznia , 1970, w dopuszczalnym zakresie obsługiwanym przez te typy danych. (coś jak od 0001-01-01 do 9999?)
Jeśli potrzebujesz przechowywać naprawdę duże dodatnie i ujemne liczby całkowite w bazie danych, prawdopodobnie przechowujesz je w kolumnie zdefiniowanej jako BIGINT .
Wewnętrzna reprezentacja kolumny DATE wymaga 3 bajtów pamięci, a DATETIME wymaga 8 bajtów pamięci (do wersji MySQL 5.6.4. Wewnętrzna reprezentacja i przechowywanie wartości DATE i DATETIME zmieniono w 5.6.4)
Więc nie, MySQL nie przechowuje wartości dat sprzed 1970 r. jako „ujemnych liczb całkowitych”.
Jeśli trochę się nad tym zastanowisz, MySQL może zaimplementować dowolny mechanizm przechowywania. (I każdy silnik pamięci masowej może dowolnie serializować tę reprezentację na dysku).
Dlaczego 3 bajty na datę?
Jedną z opcji, jaką ma MySQL (i nie twierdzę, że tak to się robi) może być rozbicie daty na składniki roku, miesiąca i dnia.
Reprezentacja wartości całkowitych w zakresie - wymaga -
-
0 - 9999 -14 bitów -
0 - 12 -4 bity -
0 - 31 -5 bitów
To w sumie 23 bity, które z łatwością mieszczą się w 3 bajtach. To tylko pokazuje, że MySQL nie musi reprezentować wartości dat sprzed 1 stycznia 1970 roku jako ujemnych liczb całkowitych, więc nie powinniśmy zakładać, że tak jest. (Ale tak naprawdę zajmowalibyśmy się tym poziomem szczegółowości, gdybyśmy pracowali nad silnikiem pamięci masowej dla MySQL.)
