1970年以前のTimestamp（負のtimestamp）

負のUnix timestampは、Unix epoch（1970年1月1日 00:00:00 UTC）より前の時点を表します。Unix timestampはepochからの経過秒数を数えるため、過去に遡ることは秒数の減算を意味し、負の値になります。例えば、-86400は1969年12月31日を表します（epochのちょうど1日前、86,400秒前）。

主要な参照点：

-1           → 1969-12-31T23:59:59Z
-86400       → 1969-12-31T00:00:00Z
-2208988800  → 1900-01-01T00:00:00Z
-62135596800 → 0001-01-01T00:00:00Z (西暦1年)

言語によるサポート状況：

// JavaScript — 正しく動作
new Date(-86400 * 1000)  // 1969-12-31T00:00:00.000Z

// Python — 正しく動作
from datetime import datetime
datetime.utcfromtimestamp(-86400)

ほとんどの現代言語は負のtimestampを正しく処理しますが、一部の古いライブラリやシステムはそうではありません。特定のプラットフォームにおけるCのmktime関数は、1970年以前の日付で失敗することがあります。MySQLのTIMESTAMP型は1970-01-01 00:00:01から2038-01-19 03:14:07のみをサポートするため、epoch以前の日付は一切格納できません。歴史的な日付が必要な場合は、代わりにDATETIMEを使用してください。

よくある落とし穴：

符号なし32ビット整数を扱う場合、負のtimestampは不可能です。範囲は0から始まります。符号なし表現を使用するシステムは、負のtimestampを暗黙的に大きな正の値に変換し、遥か未来の日付を生成します。ストレージ層がtimestampを符号付きと符号なしのどちらで扱うか、必ず確認してください。

歴史データに関する考慮事項：

アプリケーションが生年月日、歴史的イベント、アーカイブデータを扱う場合、スタック全体が1970年以前の日付をサポートしていることを確認してください。-1、0、および遠い過去の日付などの境界値でテストしましょう。歴史的な日付のタイムゾーン変換には特に注意が必要です。タイムゾーンルールは数世紀にわたって大きく変化しており、tzdataのようなライブラリでも非常に古い日付に対して正確なオフセットを持っていない場合があります。