Vi kan göra detta istället:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
FROM_UNIXTIME funktionen begränsas av det tillåtna intervallet för TIMESTAMP datatype, som är standard 32-bitars osignerade int-intervall 1970-01-01 till 2038-01-någonting. Annan programvara har uppdaterats för att stödja 64-bitars signerade heltal, men MySQL tillhandahåller ännu inte den funktionen (åtminstone inte i 5.1.x).
Lösningen i MySQL är att undvika att använda TIMESTAMP datatyp och använda DATETIME datatyp istället, när vi behöver ett större intervall (t.ex. datum före 1 januari 1970).
Vi kan använda DATE_ADD funktion för att subtrahera sekunder från 1 januari 1970, så här:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
Obs. Du kommer förmodligen att behöva ta hänsyn till tidszon "offsets" från UTC när du gör den typen av beräkningar. MySQL kommer att tolka DATETIME-värden som specificerade i time_zone inställning för den aktuella MySQL-sessionen, snarare än UTC (time_zone = '+00:00' )
UPPFÖLJNING:
F: Okej, betyder att om vi väljer datum under '1970-01-01 00:00:00' så sparas det negativa värdet i db annars skulle det vara positivt. Rätt? – mjuk genic
Svar: Ehhh, nej. Om du väljer datum-/datumtidsvärden före 1 januari 1970, kommer MySQL att returnera DATE- eller DATETIME-värden före 1 januari 1970. Om du lagrar DATE- eller DATETIME-värden före 1 januari 1970, kommer MySQL att lagra DATE- eller DATETIME-värden före 1 januari , 1970, inom det tillåtna intervallet som stöds av dessa datatyper. (något i stil med 0001-01-01 till 9999?)
Om du behöver lagra riktigt stora positiva och negativa heltal i databasen, skulle du förmodligen lagra dessa i en kolumn definierad som BIGINT .
Den interna representationen av en DATE-kolumn kräver 3-byte lagringsutrymme och DATETIME kräver 8-byte lagring (upp till MySQL version 5.6.4. Den interna representationen och lagringen av DATE- och DATETIME-värdena ändrades i 5.6.4)
Så nej, MySQL lagrar inte datumvärden före 1970 som "negativa heltal".
Om du tänker efter lite, är MySQL fri att implementera vilken lagringsmekanism de vill. (Och varje lagringsmotor är fri att serialisera den representationen till disk hur den vill.)
Varför 3 byte för ett datum?
Ett alternativ som MySQL har (och jag representerar inte att det är så det görs) kan vara att dela upp datumet i dess år, månad och dag.
Representationen av heltalsvärden i intervallet - kräver -
-
0 - 9999 -14 bitar -
0 - 12 -4 bitar -
0 - 31 -5 bitar
Det är totalt 23 bitar, vilket råkar passa in i 3 byte. Detta visar bara att det inte är nödvändigt för MySQL att representera datumvärden före 1 januari 1970 som negativa heltal, så vi bör inte anta att det gör det. (Men vi skulle egentligen bara bry oss om denna detaljnivå om vi arbetade med en lagringsmotor för MySQL.)