閉じる

UNIX時間とタイムゾーンの違いと変換の基本をやさしく解説

時間を扱うとき、UNIX時間とタイムゾーンの違いでつまずく人は少なくありません。

この記事では、UNIX時間の基礎からUTCとJSTの関係、そして相互変換の手順までを、初心者でも迷わないよう段階的にやさしく解説します。

記録はUNIX時間、表示はタイムゾーンという原則を軸に、実務で役立つ考え方も整理します。

UNIX時間とは 初心者向けの基本

エポック 1970-01-01 00:00:00 UTC

UNIX時間とは、1970-01-01 00:00:00 UTCから経過した秒数を表す数値のことです。

この起点をエポック(Unix Epoch)と呼びます

たとえばUNIX時間が0はエポックの瞬間、1は1秒後を意味します。

なぜ1970年なのか

歴史的な背景として、UNIX系システムが普及し始めた時期に合わせて定義されたためです。

重要なのは「起点が世界共通で固定されている」ことで、これにより異なるコンピュータ間でも時刻をズレなく共有できます。

UTCで固定されている

エポックはUTC(協定世界時)で固定されており、ローカルタイムゾーンの影響を受けません。

JSTで見るとエポックは1970-01-01 09:00:00になりますが、基準はあくまでUTCです。

秒10桁とミリ秒13桁の違い

UNIX時間は主に秒単位(10桁程度)ミリ秒単位(13桁程度)の2種類が使われます。

10桁と13桁の取り違いは初学者の最頻ミスで、想定よりも「約1000倍」大きな数になるため日付が大きくズレます。

よくある表記

  • 秒単位の例: 1609459200(2021-01-01 00:00:00 UTC)
  • ミリ秒単位の例: 1609459200000(同じ瞬間をミリ秒で表現)用途によって秒かミリ秒かが異なるため、API仕様を必ず確認しましょう。

単位と桁数の早見表

単位桁の目安主な用途
10桁1609459200サーバー、UNIX系ツール(dateコマンドなど)
ミリ秒13桁1609459200000フロントエンド(JavaScriptのDate.now)

秒が10桁、ミリ秒が13桁という目安を覚えておくと誤りを早期に発見できます。

UNIX時間のメリット 比較と保存が簡単

UNIX時間は数値として大小比較や並び替えがしやすいのが最大の利点です。

文字列の日付に比べ、計算や保存、インデックス最適化が容易になります。

並び替えと比較

新旧の比較や期間の判定が整数の比較で完結します。

たとえば「5分以内か」を確認する場合、現在のUNIX秒から300を引いて比較するだけです。

保存と帯域の効率

数値1つで世界共通の時刻を表現でき、JSONやデータベースに格納する際にもコンパクトです。

文字列よりも転送量が少なく、誤解釈の余地も減ります。

タイムゾーンの基礎 UTCとJST

タイムゾーンとオフセットの意味

タイムゾーンとはUTCからのズレ(オフセット)で地域の時刻を表す仕組みです。

たとえばUTC+9はUTCに9時間を足した時刻帯を指します。

オフセットとは

UTCを基準に何時間進んでいるか(または遅れているか)を示す値です。

+09:00なら9時間進んでいます。

表示だけが変わる

同じ瞬間でも、UTCでの表示とJSTでの表示は異なりますが、指している出来事は同じです。

UNIX時間はこの「同じ瞬間」を1つの数値に固定します。

UTCとJSTの違い UTC+9

JSTはUTC+9で、サマータイムは採用していません。

UTCの2021-01-01 00:00:00は、JSTでは2021-01-01 09:00:00です。

UTCとJSTの対応例

UNIX秒UTCJST(UTC+9)
01970-01-01 00:00:001970-01-01 09:00:00
16094592002021-01-01 00:00:002021-01-01 09:00:00

JSTでは常に+9時間で一定なので、DSTによる揺らぎはありません。

サマータイム DSTの注意点

サマータイム(DST)は季節に応じてオフセットが変化する制度です。

米国や欧州の多くの地域で採用されています。

UTCは揺れない

UTCはDSTの影響を受けません。

サーバー内部の基準はUTCにしておくと安全です。

JSTはDSTなし

日本時間(JST)は一年中UTC+9で固定のため、DST関連のズレは発生しません。

DSTの落とし穴

ローカル時刻で「存在しない時刻」「重複する時刻」が発生します(例: 夏時間開始・終了の切り替え瞬間)。

UTCで保持し、表示時だけタイムゾーンを適用すると安全です。

UNIX時間とタイムゾーンの違いと使い分け

記録はUNIX時間 表示はタイムゾーン

保存や計算はUNIX時間(UTC)、画面やレポート表示はユーザーのタイムゾーンにするのが基本原則です。

これによりDSTや地域差の影響を最小化できます。

典型フロー

イベント発生→UNIX時間で保存→ユーザーの設定タイムゾーンで読み出し時にフォーマット

「保存時にローカル時刻にしてしまう」設計は避けると混乱が減ります。

サーバー時刻とユーザー時刻の考え方

サーバーは内部処理とログ記録をUTCで統一します。

ユーザーに見せるときだけ、そのユーザーのタイムゾーンに合わせて変換します。

入力時の扱い

ユーザーがローカル時刻を入力した場合、その時刻がどのタイムゾーンかを明示して解釈し、UTCへ変換して保存します。

タイムゾーン未指定の文字列はあいまいです。

出力時の扱い

レポートやUIはユーザーのタイムゾーンで表示します。

同じデータでも、地域が違えば見える時刻が変わることを前提にします。

プログラミングでの判断ポイント

  • 保存・比較・集計→UNIX時間(UTC)
  • 表示・入力→ユーザーのタイムゾーン
  • 繰り返しの予定や日付だけの概念(例: 毎朝9時)はローカルの壁時計時刻として扱い、発火直前にUTCへ解決します。
  • 秒とミリ秒の単位は常に確認します。

変換の基本 UNIX時間とタイムゾーン

UNIX時間からUTC日時へ変換

UNIX時間が秒かミリ秒かを確認し、秒ならそのまま、ミリ秒なら1000で割ってUTC日時に直すのが基本です。

たとえば1609459200はUTCで2021-01-01 00:00:00、1609459200000は同じ瞬間のミリ秒表現です。

ステップ

  1. 入力値の桁数を確認(10桁なら秒、13桁ならミリ秒の目安)。
  2. ミリ秒なら1000で割って秒に正規化。
  3. UTCのカレンダー日時に変換し、ISO形式で表現します(例: 2021-01-01T00:00:00Z)。

UTCからローカル時刻 JSTへ変換

UTCの日時をJSTにするには9時間を足すだけです(JSTはUTC+09:00で固定)。

例として、2021-01-01T00:00:00ZはJSTで2021-01-01 09:00:00です。

注意

他地域ではDSTがあるため、固定の時間を足し引きしないで、タイムゾーン対応のライブラリを使います。

JSTは例外的に固定なので計算が単純です。

ローカル時刻からUNIX時間へ変換

ユーザー入力のローカル時刻をUNIX時間にするには、その時刻が属するタイムゾーンを指定してUTCへ直し、UNIX秒(またはミリ秒)に変換します。

2021-01-01 09:00:00 JST → 2021-01-01 00:00:00 UTC → 1609459200。

あいまいさの排除

タイムゾーンが欠けた日時文字列は危険です。

必ずオフセットやタイムゾーン情報を併記するか、アプリ側の既定タイムゾーンを明示しましょう。

日時文字列 ISO形式とUNIX時間の相互変換

ISO 8601形式は機械と人に優しい標準的な表記です。

代表的な書式は次の通りです。

よく使うISO例

  • 2021-01-01T00:00:00Z(UTCを意味するZ付き)
  • 2021-01-01T09:00:00+09:00(JSTを意味する+09:00付き)
  • 2021-01-01T09:00:00(オフセットなしはあいまい)

Zや+09:00の有無で解釈が変わるため、保存時はZ付きやオフセット付きに統一し、UNIX時間へはライブラリで変換します。

秒とミリ秒の取り違いを防ぐ

10桁なら秒、13桁ならミリ秒という目安をまず確認します。

さらに、値の大きさでも判別できます。

しきい値の目安

  • 秒の現在時刻はおおむね1.6e9〜2.0e9台(西暦2000〜2033年頃)
  • ミリ秒の現在時刻は1.6e12〜2.0e12台不自然に巨大または小さい値は単位ミスの可能性があります。入出力時に単位を注記し、API間で統一しましょう。

タイムゾーンのテストとデバッグのコツ

テストではUTCと各ローカルタイムの両方で同じケースを確認すると安心です。

JSTはDSTがないため基礎検証に向いていますが、DST地域の境界もサンプルに含めましょう。

実践的なヒント

  • ログにはUNIX時間とISO文字列(Z付き)を両方出力すると突合が容易です。
  • テストデータは日付の境界(00:00、23:59)や月末、うるう年を含めます。
  • DST地域では切替日前後1時間を重点確認します。
  • アプリやテスト環境のタイムゾーン設定を明示し、「どのタイムゾーンで評価しているか」を常に記録します。

サンプル変換早見表

種別解釈変換結果(UTC)変換結果(JST)
UNIX秒16094592002021-01-01 00:00:00Z2021-01-01 00:00:002021-01-01 09:00:00
UNIXミリ秒16094592000002021-01-01 00:00:00Z2021-01-01 00:00:002021-01-01 09:00:00
ISO2021-01-01T09:00:00+09:00JST2021-01-01 00:00:002021-01-01 09:00:00
ISO2021-01-01T00:00:00ZUTC2021-01-01 00:00:002021-01-01 09:00:00

同じ瞬間でも表記が変わるだけという感覚を、この表で確認できます。

まとめ

UNIX時間は世界共通の「瞬間」を数値1つで表せる強力な表現で、比較や保存が容易です。

一方、タイムゾーンは人が読むための「地域の時刻」を整える仕組みで、UTCとの差分で表されます。

実務では記録と計算はUNIX時間(UTC)、表示と入力はユーザーのタイムゾーンという原則を守ることで、多くの混乱を避けられます。

特に10桁(秒)と13桁(ミリ秒)の取り違いは頻出のため、桁数と単位を常に確認してください。

最後に、テストではUTCとローカルの両視点で検証し、ログにUNIX時間とISO表記を併記する習慣をつけると、時刻に関する不具合が格段に減ります。

この記事を書いた人
エーテリア編集部
エーテリア編集部

このサイトでは、プログラミングをこれから学びたい初心者の方に向けて記事を書いています。 基本的な用語や環境構築の手順から、実際に手を動かして学べるサンプルコードまで、わかりやすく整理することを心がけています。

クラウドSSLサイトシールは安心の証です。

URLをコピーしました!