代わりにこれを行うことができます：
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
FROM_UNIXTIME 関数は、TIMESTAMPの許容範囲によって制限されます データ型。これは、標準の32ビットunsignedint範囲1970-01-01から2038-01までです。他のソフトウェアは64ビットの符号付き整数をサポートするように更新されていますが、MySQLはまだその機能を提供していません（少なくとも5.1.xでは提供されていません）。
MySQLの回避策は、TIMESTAMPの使用を避けることです。 データ型とDATETIMEの使用 代わりに、より広い範囲が必要な場合（1970年1月1日より前の日付など）のデータ型。
DATE_ADDを使用できます 次のように、1970年1月1日から秒を引く関数：
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
N.B。 これらのタイプの計算を行う際には、UTCからのタイムゾーンの「オフセット」を考慮する必要があります。 MySQLは、DATETIME値をtime_zoneで指定されているものとして解釈します。 UTCではなく現在のMySQLセッションの設定（time_zone = '+00:00' ）
フォローアップ：
Q： さて、「1970-01-01 00:00:00」より下の日付を選択した場合、負の値はデータベースに保存され、そうでない場合は正になります。右？ –ソフトジェニック
A： ええと、違います。 1970年1月1日より前の日付/日時値を選択した場合、MySQLは1970年1月1日より前のDATEまたはDATETIME値を返します。1970年1月1日より前のDATEまたはDATETIME値を保存すると、MySQLは1月1日より前のDATEまたはDATETIME値を保存します。 、1970、これらのデータタイプでサポートされる許容範囲内。 （0001-01-01から9999のようなもの？）
本当に大きな正と負の整数をデータベースに格納する必要がある場合は、それらをBIGINTとして定義された列に格納する可能性があります。 。
DATE列の内部表現には3バイトのストレージが必要であり、DATETIMEには8バイトのストレージが必要です（MySQLバージョン5.6.4まで。5.6.4で変更されたDATE値とDATETIME値の内部表現とストレージ）
>したがって、MySQLは1970年より前の日付値を「負の整数」として保存しません。
少し考えてみると、MySQLは必要なストレージメカニズムを自由に実装できます。 （そして、各ストレージエンジンは、その表現をディスクに自由にシリアル化できます。）
なぜ日付に3バイトなのですか？
MySQLのオプションの1つ（これがその方法であることを表明しているわけではありません）は、日付を年、月、日のコンポーネントに分割することです。
-requires-
の範囲の整数値の表現-
0 - 9999 -14ビット -
0 - 12 -4ビット -
0 - 31 -5ビット
これは合計23ビットで、たまたま3バイトに収まります。これは、MySQLが1970年1月1日より前の日付値を負の整数として表す必要がないことを示しているだけなので、そうなると仮定するべきではありません。 （ただし、MySQLのストレージエンジンで作業している場合にのみ、このレベルの詳細に関心があります。）