Vi kan gøre dette i stedet:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
FROM_UNIXTIME funktion er begrænset af det tilladte interval for TIMESTAMP datatype, som er standard 32-bit usigneret int-interval 1970-01-01 til 2038-01-noget. Anden software er blevet opdateret til at understøtte 64-bit signerede heltal, men MySQL leverer endnu ikke den funktionalitet (i hvert fald ikke i 5.1.x).
Løsningen i MySQL er at undgå at bruge TIMESTAMP datatype og bruge DATETIME datatype i stedet, når vi har brug for et større interval (f.eks. datoer før 1. januar 1970).
Vi kan bruge DATE_ADD funktion til at trække sekunder fra 1. januar 1970, sådan her:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
NB Du skal sandsynligvis tage højde for tidszone-"forskydninger" fra UTC, når du udfører disse typer beregninger. MySQL vil fortolke DATETIME-værdier som værende angivet i time_zone indstilling af den aktuelle MySQL-session i stedet for UTC (time_zone = '+00:00' )
OPFØLGNING:
Sp: Okay, betyder, at hvis vi vælger datoer under '1970-01-01 00:00:00', så gemmer den negative værdi i db'en, ellers ville den være positiv. Ret? – blød genisk
A: Øhhh nej. Hvis du vælger dato-/datotidsværdier før 1. januar 1970, vil MySQL returnere DATE- eller DATETIME-værdier før 1. januar 1970. Hvis du gemmer DATE- eller DATETIME-værdier før 1. januar 1970, vil MySQL gemme DATE- eller DATETIME-værdier før 1. januar , 1970, inden for det tilladte område, der understøttes af disse datatyper. (noget i stil med 0001-01-01 til 9999?)
Hvis du har brug for at gemme virkelig store positive og negative heltal i databasen, vil du sandsynligvis gemme dem i en kolonne defineret som BIGINT .
Den interne repræsentation af en DATE-kolonne kræver 3-bytes lagring, og DATETIME kræver 8-bytes lagring (op til MySQL version 5.6.4. Den interne repræsentation og lagring af DATE- og DATETIME-værdier ændret i 5.6.4)
Så nej, MySQL gemmer ikke datoværdier før 1970 som "negative heltal".
Hvis du tænker lidt over det, er MySQL fri til at implementere hvilken lagringsmekanisme de ønsker. (Og hver lagermotor er fri til at serialisere denne repræsentation til disk, som den vil.)
Hvorfor 3 bytes for en date?
En mulighed MySQL har (og jeg repræsenterer ikke, at det er den måde, det gøres på) kunne være at dele datoen op i dets år, måned og dag.
Repræsentationen af heltalsværdier i området - kræver -
-
0 - 9999 -14 bit -
0 - 12 -4 bit -
0 - 31 -5 bit
Det er i alt 23 bits, som tilfældigvis passer ind i 3 bytes. Dette viser blot, at det ikke er nødvendigt for MySQL at repræsentere datoværdier før 1. januar 1970 som negative heltal, så vi bør ikke antage, at det gør. (Men vi ville egentlig kun være bekymrede over dette detaljeringsniveau, hvis vi arbejdede på en storage-motor til MySQL.)