Místo toho můžeme udělat toto:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
FROM_UNIXTIME funkce je omezena povoleným rozsahem pro TIMESTAMP datový typ, což je standardní 32bitový int rozsah bez znaménka 1970-01-01 až 2038-01-něco. Další software byl aktualizován, aby podporoval 64bitová celá čísla se znaménkem, ale MySQL zatím tuto funkci neposkytuje (alespoň ne ve verzi 5.1.x).
Řešením v MySQL je vyhnout se používání TIMESTAMP datový typ a pomocí DATETIME místo toho datový typ, když potřebujeme větší rozsah (např. data před 1. lednem 1970).
Můžeme použít DATE_ADD funkce k odečtení sekund od 1. ledna 1970 takto:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
N.B. Při provádění těchto typů výpočtů budete pravděpodobně muset počítat s „posuny“ časového pásma od UTC. MySQL bude interpretovat hodnoty DATETIME jako hodnoty specifikované v time_zone nastavení aktuální relace MySQL, nikoli UTC (time_zone = '+00:00' )
NÁSLEDUJÍCÍ:
O: Dobře, znamená to, že pokud vybereme data pod '1970-01-01 00:00:00', pak se záporná hodnota uloží do db, jinak by byla kladná. Že jo? – soft genic
Odpověď: Uhhh, ne. Pokud vyberete hodnoty data/datetime před 1. lednem 1970, MySQL vrátí hodnoty DATE nebo DATETIME před 1. lednem 1970. Pokud uložíte hodnoty DATE nebo DATETIME před 1. lednem 1970, MySQL uloží hodnotu DATE nebo DATETIME před 1. lednem , 1970, v povoleném rozsahu podporovaném těmito datovými typy. (něco jako 0001-01-01 až 9999?)
Pokud potřebujete v databázi uložit opravdu velká kladná a záporná celá čísla, pravděpodobně je uložíte do sloupce definovaného jako BIGINT .
Interní reprezentace sloupce DATE vyžaduje 3 bajty úložiště a DATETIME vyžaduje 8 bajtů úložiště (až do verze MySQL 5.6.4. Interní reprezentace a úložiště hodnot DATE a DATETIME se změnilo v 5.6.4)
Takže ne, MySQL neukládá hodnoty data před rokem 1970 jako "záporná celá čísla".
Pokud se nad tím trochu zamyslíte, MySQL si může zdarma implementovat jakýkoli mechanismus úložiště, který chtějí. (A každý úložný stroj může tuto reprezentaci serializovat na disk, jak chce.)
Proč 3 bajty pro datum?
Jednou z možností, kterou MySQL má (a já netvrdím, že to je způsob, jakým se to dělá) by mohlo být rozdělit datum na komponenty rok, měsíc a den.
Reprezentace celočíselných hodnot v rozsahu - vyžaduje -
-
0 - 9999 -14 bitů -
0 - 12 -4 bity -
0 - 31 -5 bitů
To je celkem 23 bitů, což se náhodou vejde do 3 bajtů. To jen ukazuje, že není nutné, aby MySQL reprezentovalo hodnoty data před 1. lednem 1970 jako záporná celá čísla, takže bychom neměli předpokládat, že tomu tak je. (Ale o tuto úroveň detailů bychom se skutečně zabývali pouze tehdy, pokud bychom pracovali na úložném enginu pro MySQL.)