We kunnen dit in plaats daarvan doen:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
De FROM_UNIXTIME functie wordt beperkt door het toegestane bereik voor de TIMESTAMP datatype, het standaard 32-bits niet-ondertekende int-bereik 1970-01-01 tot 2038-01-iets. Andere software is bijgewerkt om 64-bits ondertekende gehele getallen te ondersteunen, maar MySQL biedt die functionaliteit nog niet (tenminste niet in 5.1.x).
De tijdelijke oplossing in MySQL is het vermijden van het gebruik van de TIMESTAMP datatype en met behulp van de DATETIME datatype in plaats daarvan, wanneer we een groter bereik nodig hebben (bijv. datums vóór 1 jan. 1970).
We kunnen de DATE_ADD . gebruiken functie om seconden van 1 jan. 1970 af te trekken, als volgt:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
NB U zult waarschijnlijk rekening moeten houden met tijdzone "offsets" van UTC bij het uitvoeren van dit soort berekeningen. MySQL gaat DATETIME-waarden interpreteren als gespecificeerd in de time_zone instelling van de huidige MySQL-sessie, in plaats van UTC (time_zone = '+00:00' )
VERVOLG:
V: Oké, betekent dat als we datums selecteren onder '1970-01-01 00:00:00', de negatieve waarde wordt opgeslagen in de db, anders zou het positief zijn. Rechts? – zacht geneen
A: Euh, nee. Als u datum/datum/tijd-waarden vóór 1 januari 1970 selecteert, retourneert MySQL DATE- of DATETIME-waarden vóór 1 januari 1970. Als u DATE- of DATETIME-waarden vóór 1 januari 1970 opslaat, zal MySQL de DATE- of DATETIME-waarde vóór 1 januari opslaan , 1970, binnen het toegestane bereik dat door die datatypes wordt ondersteund. (zoiets als 0001-01-01 tot 9999 ?)
Als u echt heel grote positieve en negatieve gehele getallen in de database moet opslaan, zou u die waarschijnlijk opslaan in een kolom die is gedefinieerd als BIGINT .
De interne weergave van een DATE-kolom vereist 3 bytes opslagruimte en DATETIME vereist 8 bytes opslagruimte (tot MySQL-versie 5.6.4. De interne weergave en opslag van DATE- en DATETIME-waarden is gewijzigd in 5.6.4)
Dus nee, MySQL slaat datumwaarden vóór 1970 niet op als "negatieve gehele getallen".
Als je er een beetje over nadenkt, is MySQL vrij om elk opslagmechanisme te implementeren dat ze willen. (En elke opslagengine is vrij om die representatie naar schijf te serialiseren zoals hij wil.)
Waarom 3 bytes voor een datum?
Een optie die MySQL heeft (en ik zeg niet dat dit de manier is waarop het wordt gedaan) zou kunnen zijn om de datum op te splitsen in zijn jaar, maand- en dagcomponenten.
De weergave van gehele waarden in het bereik - vereist -
-
0 - 9999 -14 bits -
0 - 12 -4 bits -
0 - 31 -5 bits
Dat zijn in totaal 23 bits, wat toevallig in 3 bytes past. Dit toont alleen maar aan dat het niet nodig is voor MySQL om datumwaarden vóór 1 jan. 1970 weer te geven als negatieve gehele getallen, dus we moeten er niet vanuit gaan dat dit wel het geval is. (Maar we zouden ons alleen zorgen maken over dit detailniveau als we aan een opslagengine voor MySQL werkten.)