UTC
世界の基準となる時刻です。ログや国際的なデータ交換ではUTC表示を一緒に確認すると誤解を減らせます。
Unix time guide
Unixタイムスタンプを
基礎から理解する
数字だけで日時を表す仕組み、1970年の起点、秒とミリ秒の違い、UTCとの関係、負数、うるう秒、2038年問題を順番に解説します。
Unixタイムスタンプとは
1970年1月1日00:00:00 UTCを0として、そこから経過した時間を数値で表したものです。
最も短い説明：カレンダーの「2024年1月1日」の代わりに、共通の起点から何秒経過したかを記録する方式です。
年・月・日という表示は地域や暦の見せ方に左右されますが、1つの経過時間ならシステム間で比較しやすくなります。例えば0秒は起点そのもの、1秒はその1秒後、-1秒は1秒前です。
Unixタイムスタンプ、Unix time、Epoch timeという言葉は日常的には同じ仕組みを指すことが多いものの、「エポック」はシステムごとの基準時刻という広い意味でも使われます。データ仕様では起点と単位を確認してください。
既知の値で仕組みを確認
基準値を覚えておくと、単位やタイムゾーンの誤りをすばやく見つけられます。
| Unix秒 | UTC | 意味 |
|---|---|---|
-1 | 1969-12-31 23:59:59 | 起点の1秒前 |
0 | 1970-01-01 00:00:00 | Unixエポック |
946684800 | 2000-01-01 00:00:00 | 2000年の開始 |
2147483647 | 2038-01-19 03:14:07 | 32ビット符号付き秒の最大値 |
秒・ミリ秒・マイクロ秒・ナノ秒
Unix時刻という名前だけでは単位が決まりません。同じ瞬間でも用途によって4つの大きさが使われます。
| 単位 | 1秒あたり | 現在付近の桁数 | 例 |
|---|---|---|---|
| 秒 (s) | 1 | 約10桁 | 1704067200 |
| ミリ秒 (ms) | 1,000 | 約13桁 | 1704067200000 |
| マイクロ秒 (μs) | 1,000,000 | 約16桁 | 1704067200000000 |
| ナノ秒 (ns) | 1,000,000,000 | 約19桁 | 1704067200000000000 |
桁数は目安です。古い日時、遠い未来、負数では桁数が変わります。列名やAPI仕様に単位があるなら、それを最優先してください。
Unix値とタイムゾーンの関係
Unix値そのものはタイムゾーンを持たず、世界中で同じ瞬間を指します。タイムゾーンは人が読む日時へ変えるときに使います。
日本標準時 JST
UTC+09:00です。日本に設定された端末では、端末時刻の表示が通常JSTになります。
韓国標準時 KST
現在はJSTと同じUTC+09:00です。どちらも夏時間による季節変更はありません。
例：
1704067200秒は2024-01-01 00:00:00 UTCで、JSTとKSTでは2024-01-01 09:00:00です。数値は同じまま、表示だけが変わります。負のUnix時刻
0より小さい値はエラーとは限りません。起点より前の日時を表す正当な値です。
-1秒は1969-12-31 23:59:59 UTC、-86400秒は1969-12-31 00:00:00 UTCです。ただし古いシステムやデータベースの型によっては負数を扱えない場合があります。
負数の丸め：-0.5秒を整数へ変えるとき、0方向へ切り捨てるか負の無限大方向へ切り下げるかで結果が変わります。保存先の仕様を確認してください。
うるう秒とUnix時刻
地球の自転と原子時計の差を調整するうるう秒は、一般的なPOSIX方式のUnix時刻では独立した追加秒として数えません。
そのため通常のUnix変換では23:59:60を一般的なカレンダー秒として表しません。うるう秒の直前と直後の扱いはOS、時刻同期方式、データ提供元によって異なることがあります。科学計測や監査など秒の連続性が重要な場合は、元システムの時刻尺度と補正方式を確認してください。
参照：POSIX時間とうるう秒の考え方はThe Open Groupの時間解説で確認できます。
2038年問題
Unix秒を32ビット符号付き整数に保存すると、表現できる最大値は2147483647です。
境界：
2147483647秒は2038-01-19 03:14:07 UTCです。次の1秒を同じ形式で表そうとすると範囲を超えます。古いOS、組み込み機器、ファイル形式、データベース列ではこの制限が残っていることがあります。新しい実装では64ビット整数や、範囲を明示した日時型が一般的です。現在動いている画面だけでなく、保存形式、通信形式、受け取り側の型まで確認する必要があります。
Unix時刻とISO 8601の使い分け
機械処理にはUnix値、人が読む共有にはオフセット付きISO形式が便利です。
| 形式 | 長所 | 注意点 |
|---|---|---|
| Unix秒 | 短く、差分計算や並べ替えが簡単 | 単位と人が読める日時が分かりにくい |
| Unixミリ秒 | 1秒未満の順序を扱える | 秒との1000倍違いに注意 |
| ISO 8601 / RFC 3339 | 日付とタイムゾーンを一緒に読める | Zまたはオフセットを省略しない |
外部へ共有するときは、必要に応じてUnix値と2024-01-01T00:00:00ZのようなISO形式を併記すると検算しやすくなります。
日時形式：インターネット上で使う日時形式はRFC 3339を参照できます。
タイムスタンプを受け取ったときの確認順
次の4点を順に確認すると、多くの変換ミスを防げます。
- 単位：秒、ミリ秒、マイクロ秒、ナノ秒のどれか。
- 符号と小数：負数や秒未満の精度を受け取れるか。
- 日時表示：変換後のUTCが記録の時期と合うか。
- 保存先：32ビット範囲や整数精度の制限がないか。
よくある質問
Unix時刻の基本概念と注意点をまとめました。
Unixタイムスタンプはどのタイムゾーンですか？
タイムスタンプ自体に地域のタイムゾーンはありません。1970年1月1日00:00:00 UTCからの経過時間で瞬間を表し、表示するときにUTC、JST、KSTなどを選びます。
Unixタイムスタンプが10桁または13桁なのはなぜですか？
現在付近では秒単位が約10桁、ミリ秒単位が約13桁になるためです。両者は同じ瞬間でも1000倍の差があります。
Unix時刻にうるう秒は含まれますか？
一般的なPOSIX方式のUnix時刻は、うるう秒を独立した追加の秒として数えません。システム固有の補正方法がある場合はその仕様を確認してください。
2038年問題とは何ですか？
Unix秒を32ビット符号付き整数で保存すると、2038年1月19日03:14:07 UTCの次で表現範囲を超える問題です。64ビット形式では実用上はるかに広い範囲を扱えます。
理解した内容を実際に確認
用途に合わせて変換ツールを選べます。