UNIXタイムスタンプを安全に変換し、タイムゾーンを管理する

UNIXタイムスタンプは、UNIXエポックから経過した時間として時点を表します。名前付きタイムゾーン、夏時間規則、カレンダー名は保存しません。人や場所に時点を表示するとき、これらの規則を追加します。

簡単な回答： 最初に単位を決めます。現在の10桁の値は秒であることが多いです。現在の13桁の値はミリ秒であることが多いです。値を時点に変換します。その後、UTCまたは名前付きIANAタイムゾーンで書式化します。固定UTCオフセットを完全なタイムゾーンとして扱わないでください。

このユースケースでは、エポック単位、負の値、UTC、オフセット、季節変化、ISO 8601テキスト、JavaScriptの制限、Windowsファイル時刻の変換を説明します。これらの用語をUNIX Timestamp Converterと日付、時刻、タイムスタンプのコレクションに結び付けます。

UNIXタイムスタンプとは何ですか？

UNIXエポックは1970-01-01 00:00:00 UTCに始まります。UNIXタイムスタンプは通常、うるう秒を除く基準時点からの秒を数えます。正の値は後の時点を示します。システムが対応する場合、負の値は前の時点を示します。

POSIX時間モデルは、エポックからの秒とカレンダー変換規則を定義します。RFC 9636はUNIX時間を定義します。これは、POSIXエポックからのうるう秒なしの整数秒です。実装とプログラミング言語は、より狭い範囲または異なる数値精度を強制することがあります。

タイムスタンプは、表示される日付と同じではありません。ある時点は、東京、コルカタ、ロンドン、ニューヨークで異なる現地の日付になります。タイムスタンプは変わりません。各場所がタイムゾーン規則を適用するため、表示が変わります。

値の種類	例	意味	主なリスク
UNIX秒	`1725148800`	エポックからの秒	ミリ秒との取り違え
UNIXミリ秒	`1725148800000`	エポックからのミリ秒	秒との取り違え
`Z`付きISO日付	`2024-09-01T00:00:00Z`	UTCの時点	パース中に`Z`を失う
オフセット付きISO日付	`2024-09-01T05:30:00+05:30`	時点と数値オフセット	オフセットを名前付きゾーンとして扱う
現地日付	`2024-09-01 05:30`	一意でない時点のカレンダーフィールド	ゾーンと重複時の選択がない

UNIXタイムスタンプはタイムゾーンに依存しますか？

いいえ。有効なUNIXタイムスタンプは、表示タイムゾーンに関係なく時点を識別します。タイムゾーンは、時点と現地のカレンダーフィールド間の変換に影響します。

直接の回答： UNIX値のタイムゾーンを「変換」するために、現地のUTCオフセットを加算または減算しないでください。時点を保持します。タイムゾーンライブラリに対象ゾーンで書式化させます。

場所がオフセットを変更すると、手動のオフセット計算は失敗します。夏時間は季節による変更を作ることがあります。政府は市民時間の規則を改訂できます。過去のオフセットは現在と異なる場合があります。整数時間のオフセットを使わない地域もあります。

IANAタイムゾーンデータベースは、代表的な場所の現在および過去の市民時間規則を記録します。規則が変わると、システムはこのデータベースを更新します。America/New_Yorkには規則の履歴があります。-05:00には数値オフセットだけがあります。

秒とミリ秒をどのように区別しますか？

どの日時にも通用する桁数の規則はありません。規模は、現在のデータへの実用的な手がかりになります。正式な型システムではありません。堅牢なインターフェースは、単位を要求するか、推定を表示します。

現在に近いUNIX秒は、約10桁であることが多いです。ミリ秒は約13桁であることが多いです。マイクロ秒とナノ秒はさらに大きな値を使います。未来の日付、負の日付、先頭ゼロ、10進値、文字列では、長さの検査が無効になることがあります。

安全な手順を使います。

ソースシステムの文書を読みます。
単位と数値範囲が分かるまで、値をテキストとして保持します。
秒、ミリ秒、マイクロ秒、ナノ秒を明示的に選びます。
重要な精度には、整数用ライブラリを使います。
結果の年を、想定する業務範囲と比較します。
想定するUTCと名前付きタイムゾーンを表示します。

1725148800で1970年1月の日付になる場合、コンバーターは秒をミリ秒として扱った可能性があります。1725148800000で数千年離れた日付になる場合、ミリ秒を秒として扱った可能性があります。もっともらしい年は検査に役立ちます。ソースの文書が最優先です。

JavaScriptで時間精度が失われる理由は何ですか？

JavaScriptのNumberは、IEEE 754に従う2進浮動小数点値を使います。整数を正確に表せるのは定義された安全範囲内だけです。現在に近いミリ秒は問題なく収まります。ナノ秒は収まりません。

ECMAScriptのDateは時間値をミリ秒で保存します。ECMAScriptの日付仕様は値と許容範囲を定義します。実装は範囲外の値を拒否します。パースも入力文法と存在するゾーンに依存します。

マイクロ秒またはナノ秒にはBigIntまたは適切なライブラリを使います。範囲を確認する前に大きな整数文字列をNumberに変換しないでください。変換は下位の桁を黙って丸め、時点を変えることがあります。

APIがタイムスタンプを返す場合、フィールド名またはスキーマに単位を文書化します。createdAtEpochSecondsはtimestampより安全です。JSONは構文以外で整数サイズを区別しません。プロデューサーとコンシューマーには契約が必要です。

UTC、オフセット、名前付きゾーンの違いは何ですか？

UTCは、世界の時点で共有する時間標準です。UTCオフセットは、ある時点の現地時間とUTCの差を示します。名前付きゾーンは、日付に基づいてオフセットを決める規則を提供します。

用語	例	日付で変わるか	それだけで時点を識別するか
UTCマーカー	`Z`	いいえ	日付と時刻があれば、はい
数値オフセット	`+05:30`	値は変わらない	日付と時刻があれば、はい
IANAゾーン	`Asia/Kolkata`	変わることがある	現地の日付と時刻なしでは、いいえ
現地の壁時計時刻	`2026-11-01 01:30`	該当なし	いいえ

名前付きゾーンは、戻しの間に現地時刻を2つの時点に対応付けることがあります。進みの間には対応する時点がないことがあります。ライブラリはこれらを重複と空白と呼びます。アプリケーションには解決規則が必要です。

予定イベントでは、意図した意味を保存します。1回限りの会議は時点と表示ゾーンを保存できます。09:00の繰り返し予定には、現地時間、名前付きゾーン、繰り返し規則、データベース変更時の動作が必要な場合があります。最初の時点だけ保存すると、将来の予定が移動することがあります。

夏時間の変化では何が起きますか？

春の変更では時計が進むことがあります。現地時間の区間が存在しなくなります。秋の変更では時計が戻ることがあります。現地時間の区間が異なるオフセットで2回現れることがあります。

現地の時計が01:30を2回表示するとします。現地の日付と時刻だけの文字列では、どちらの時点を意味するか分かりません。数値オフセットを追加するか、名前付きゾーンのライブラリで前後を明示する規則を適用します。

ECMAScriptの提案であるTemporalは、これらの違いをモデル化します。ZonedDateTimeの文書は、正確な時点、ゾーン、カレンダーを説明します。空白と重複の解決動作も説明します。提案インターフェースに依存する前に、対応と本番状態を確認します。

ゾーンオフセットを無期限にキャッシュしないでください。IANAデータを提供する環境またはデータベースを更新します。サーバー、クライアント、コンテナ、データベースイメージを最新に保ちます。古いデータでは、2つのサービスが同じ将来イベントに異なる現地時刻を計算することがあります。

時点はどのように書式化すべきですか？

明示的なUTCマーカーまたはオフセットを含む、機械可読形式を使います。RFC 3339は、インターネットで一般的な日付時刻プロファイルを定義します。RFC 3339仕様は完全な日付、完全な時刻、オフセット、任意の小数を定義します。

例：

2026-09-01T12:00:00ZはUTCの正午を示します。
2026-09-01T17:30:00+05:30はオフセット付きで同じ時点を示します。
2026-09-01T12:00:00.123Zはミリ秒精度を追加します。
2026-09-01 12:00:00はゾーンもオフセットも説明しません。

相互運用性が重要なら、TとZを大文字で使います。必要な小数精度を保持します。意味のない桁を追加しません。秒精度のソースに9個のゼロを追加しても、ナノ秒精度にはなりません。

名前付きゾーンを持つ新しいプロトコルでは、RFC 9557の拡張形式を確認します。ゾーン名を含む情報を、角括弧でRFC 3339タイムスタンプに追加します。導入前に、すべてのコンシューマーの対応を確認します。

うるう秒はUNIX時間にどう影響しますか？

UTCには、ときどきうるう秒があります。一般的なUNIXおよびPOSIX表現は、通常の連続した対応付けで各うるう秒ラベルに一意の標準タイムスタンプを割り当てません。システムは、イベントを無視、反復、平滑化、または特別な時計で処理することがあります。

IANAのtzプロジェクトは、理論タイムゾーンファイルで判断と制限を文書化しています。時間ライブラリは、科学的な高精度測定より市民時間のタイムスタンプを対象とすることが多いです。

アプリケーションが金融シーケンス、衛星データ、分散ログ、科学測定を扱う場合、時間尺度を定義します。UTC、TAI、GPS時間、単調時計、システム時計は異なる問題を解決します。ブラウザーコンバーターを高精度時間の権威にしないでください。

プロセス内の期間を測定するには単調時計を使います。市民時計は、同期、管理、仮想マシンによって変わることがあります。監査用にイベント時点を保存します。コード実行時間は、プラットフォームの単調インターフェースで測定します。

UNIXタイムスタンプを安全に変換する方法

次の手順に従います。

ソースシステムと単位を識別します。
監査と診断のために元の値を保持します。
構文、符号、範囲、許容精度を検証します。
現地オフセットを手動で適用せず、値を時点に変換します。
時点をUTCの安定した参照として書式化します。
同じ時点を要求されたIANAゾーンで書式化します。
その日付に使った数値オフセットを表示します。
年と現地コンテキストを想定値と比較します。

UNIX Timestamp Converterは、対象を絞った変換手順を提供します。サンプルデータから始めます。ブラウザーツールは値の検査に役立ちます。正しい単位は、ソースAPIの契約で決まります。

大量または本番の変換には、保守されたライブラリを使います。ゾーンデータを固定して更新します。空白と重複、年の境界、負の値、小数、最大許容値のテストを追加します。

Windowsファイル時刻の違いは何ですか？

Windowsファイル時刻とUNIX時間は、異なるエポックと単位を使います。FILETIMEは通常、1601-01-01 UTCからの100ナノ秒間隔を数えます。UNIX時間は通常、1970-01-01 UTCからの秒を数えます。

変換には、エポックオフセットと単位係数が必要です。FILETIMEはJavaScriptの安全範囲を超えることがあるため、大きな整数の算術が重要です。Numberを介した変換は、末尾の桁を失うことがあります。

管理された変換にはUNIX to Windows Filetimeツールを使います。逆方向にはWindows Filetime to UNIXツールを使います。元の整数をテキストとして保持します。フォレンジック精度が重要なら、別の実装で結果を確認します。

Windowsのファイル時刻の文書は、100ナノ秒間隔を説明します。ファイルシステムは異なる分解能、更新、現地変換を使うことがあります。公称単位だけでは、ソースがその精度で測定したことは証明できません。

データベースとAPIへの推奨

モデルに合う型を使います。ゾーン付きデータベースタイムスタンプは時点を正規化できますが、各プロバイダーの意味は異なります。ゾーンなしのタイムスタンプは、現地フィールドを表すことがあります。移行を設計する前に文書を読みます。

APIイベントには、Z付きRFC 3339文字列、または明示的な単位を持つ文書化された整数を送ります。文書化されていない値は避けます。業務上の意味がある場合は、名前付きゾーンを別に送ります。

現地時刻を安定させる必要がある将来の予定には、時点だけでなく多くの情報を保存します。役立つレコードには、次の項目を含められます。

現地の日付と時刻
IANAゾーン識別子
繰り返し規則
解決時の選択
元のユーザー入力
次に計算された時点
規則更新の方針

過去のイベントログには、時点と有用なコンテキストを保存します。オフセットは表示と診断に役立ちます。人間の解釈では、名前付きゾーンも重要な場合があります。

タイムスタンプでよくある間違い

間違い1：桁数だけで単位を推測する

桁数は手がかりです。契約ではありません。ソース単位と想定範囲を確認します。

間違い2：ゾーン変更のためにオフセットを加算する

この操作は時点を変えます。時点を保持し、対象ゾーンで書式化します。

間違い3：略称をゾーンとして使う

CSTのような略称は、複数の場所またはオフセットを示すことがあります。IANA識別子または文書化された数値オフセットを使います。

間違い4：ゾーンなしで日付と時刻をパースする

パーサーは、デバイスゾーン、UTC、別の規則を仮定することがあります。時点には明示的なオフセットを要求します。現地の予定は名前付きゾーンでモデル化します。

間違い5：季節による空白と重複を無視する

現地時刻には、存在しないものや2回現れるものがあります。テストケースと解決規則を追加します。

間違い6：浮動小数点で大きなタイムスタンプを変換する

マイクロ秒、ナノ秒、FILETIMEの整数は精度を失うことがあります。文字列または任意精度の整数として保持します。

間違い7：セキュリティにクライアント時計を使う

デバイス時計は間違っていたり、改ざんされたりします。セキュリティプロトコルには、サーバー検証、有効期限の許容、リプレイ保護、信頼できる時間ソースが必要です。

確認リスト

変換を受け入れる前に、次の質問に答えます。

確認	理由
ソースはどの単位を使うか？	1,000倍の係数エラーで日付が誤る
入力は整数か小数か？	小数が精度を変えることがある
値は負になり得るか？	一部のシステムはエポック前の日付を拒否する
数値型は値を保持するか？	丸めで下位単位が変わることがある
出力はUTCか名前付きゾーンか？	現地名称には規則が必要
現地時刻は1回だけ現れるか？	季節の時間で空白と重複が生じる
どのデータベース版を適用するか？	将来の市民時間規則は変わることがある
ソースはどの精度で測定したか？	保存された桁が精度を過大に見せることがある

この一覧は曖昧な数値を文書化された変換にします。エラー報告も改善します。元の値、単位、想定時点、対象ゾーン、環境、ゾーンデータ版を含めます。

よくある質問

UNIX時間は常に秒を使いますか？

従来の表現は秒を使います。多くのAPIはミリ秒、マイクロ秒、ナノ秒を使い、フィールドをUNIX時間と呼びます。スキーマと単位を読みます。

UNIX時間にはタイムゾーンが含まれますか？

いいえ。エポックに対する時点を識別します。現地のカレンダーフィールドを作るとき、名前付きゾーンを適用します。

`0`のタイムゾーンは何ですか？

通常のモデルでは、UNIX値0は1970-01-01 00:00:00 UTCに対応します。現地表示では、別の日付または時刻になることがあります。

コンバーターが1970年を表示する理由は何ですか？

最も一般的な原因は、単位が誤っていることです。秒の値をミリ秒として扱うと、エポック付近になります。単位を確認します。

2つのコンバーターが1時間ずれる理由は何ですか？

異なるゾーン、季節規則、データベース版、曖昧さの規則を使っている可能性があります。UTC出力と名前付きゾーンを比較します。

UTCはGMTと同じですか？

日常のオフセット表示では、同じように使われることがあります。技術的な歴史は異なります。明示的なプロトコルと標準にはUTCを使います。

繰り返し会議にUTCタイムスタンプだけを保存できますか？

会議が現地時刻を維持する必要がある場合は、できません。名前付きゾーンと繰り返しの意味を保存します。現在の規則で将来の時点を計算します。

ISO 8601とUNIX時間のどちらを使いますか？

インターフェースに合う表現を使います。RFC 3339テキストは読みやすく、オフセットを含みます。整数は簡潔ですが、文書化された単位が必要です。どちらも同じ時点を表せます。

最終的な変換規則

UNIXタイムスタンプは時点を識別します。タイムゾーンは、その時点が現地の時計にどう現れるかを説明します。これらの用語を分けて扱います。

変換前に単位を確認します。整数の精度を保持します。安定した参照としてUTCを表示します。現地出力にはIANAゾーンを使います。季節の境界と過去のデータをテストします。これらの手順により、本番データで多くの失敗を防げます。