UNIX時間から日付へ変換｜固定UTCオフセット対応

使い方

1. 変換元が秒単位のUNIX時間であることを確認し、整数秒を入力します。
2. 対象時点の固定UTCオフセットをlocal−UTCの分で入力します。UTC表示は0、JSTは540です。
3. 結果の年月日時分秒を確認し、元秒、オフセット、単位、参照した地域規則を記録します。

計算式・考え方

L=UNIX秒+60×固定オフセット分、d=floor(L/86400)、S=135140+d、r=L−86400dとし、SをGregorian年月日へ、rを時分秒へ分解します。offset=local−UTCです。

注意事項

• UNIX秒Uとオフセット分Oから現地総秒L=U+60Oを作り、日差d=floor(L/86400)、通算日S=135140+d、日内秒r=L−86400dとします。Sから年月日を逆算し、rを3600と60で順に分解して時分秒を求めます。
• 既定値U=0、O=540では1970-01-01 09:00:00です。U=−1、O=0では1969-12-31 23:59:59となります。負数のfloorと正の剰余が正しく働く代表例なので、古い日時を扱う実装の検算に利用できます。
• 入力UNIX秒は−11676146400から253402351199まで許可しますが、オフセット適用後の通算日も検査します。下限秒に−840分を組み合わせると範囲外、下限秒に+840分なら1600-01-01 00:00:00となるなど、同じ秒でも差により可否が変わります。
• 結果欄は年、月、日、時、分、秒を個別に返します。ゼロ埋め文字列ではなく整数成分なので、ISO形式へ組み立てるときは月日・時分秒を二桁に整え、オフセット符号も付けてください。本ページ自体は地域名やZ表記を自動付与しません。
• UNIX秒だけでは利用者が意図した現地時刻は決まりません。UTC表示ならO=0、日本標準時の固定差なら540を指定します。過去の日本で常に+540だったと仮定する機能ではないため、歴史時刻を調べる場合は該当時点の公的資料から差を入力してください。
• 監視ログの秒を調べる場合は、収集元がUNIX秒を文字列で出したのか、符号付き整数で出したのかも確認します。負数を未対応値として0へ置換する古い処理や、秒をローカルepochから数える独自仕様があると、本ページのPOSIX基準とは一致しません。既知のepoch値を一件照合してから大量のログへ適用します。
• オフセットで日付が変わる例として、UTCの前日深夜へ負の差を加える場合と、翌日早朝へ正の差を加える場合があります。年月日だけを比較すると同じ瞬間を別日と誤解しやすいため、結果を共有するときは少なくとも時分秒と数値オフセットを併記し、元のUNIX秒も削除しないでください。
• UNIX時間は1970-01-01 00:00:00 UTCを0とし、その前を負、後を正の整数秒で表します。The Open GroupのPOSIX General Conceptsと関連根拠資料を2026年7月13日に照合し、本ページは互換性のある各日86,400秒のモデルを採用します。表示する年月日は先発グレゴリオ暦です。
• POSIX時間は過去のうるう秒を秒数へ加えません。UTCで23:59:60と表される瞬間、TAI、UT1、天文時刻、原子時計の厳密な経過秒を再現する計算ではありません。ログの前後関係がうるう秒境界に依存する場合は、利用システムの時刻尺度と公式な変換表を確認してください。
• 数値オフセットはRFC 3339と同じくlocal time−UTCです。JSTのUTC+09:00は+540分なので、UTCから現地日時へは540分を足し、現地日時からUTCへは540分を引きます。正負を逆にしやすいため、式だけでなく既定例の1970-01-01 09:00 JST=UNIX 0で方向を確認します。
• オフセットは−840分から+840分までの固定整数です。地域名、夏時間、歴史的な標準時変更、政治的なタイムゾーン改定を検索しません。同じ都市でも日時により差が変わる場合があるため、利用者が対象時点に適用する差を資料から決めて入力します。現在の端末設定を暗黙に使いません。
• 対応する暦日は1600-01-01から9999-12-31までです。月の日数とうるう年は既存のGregorian関数で検査し、四で割れる年を基本に百で割れる年を平年、四百で割れる年を再びうるう年とします。1900-02-29は拒否し、2000-02-29は受け付けます。
• 秒は整数だけを扱い、23:59:60のうるう秒やミリ秒、小数秒を受け付けません。JavaScript Dateへ渡さず、通算日と日内秒を許可制ASTで計算します。入力した整数は対応範囲でbinary64の安全整数内にあり、日付成分とUNIX秒を丸めずに表せます。
• 負の総秒を日へ分解するときは0方向への切り捨てではなくfloorを使います。例えば−1秒は日差−1、日内秒86,399となり、1969-12-31 23:59:59へ正規化されます。剰余が負のまま時刻欄へ出ないよう、日内秒を必ず0から86,399へ収めます。
• 入力、暦検査、加減算、結果描画はブラウザー内だけで完結します。外部API、タイムゾーン配信、現在時刻取得、ファイルアップロード、サーバー保存を行いません。同じ入力なら後日も同じ固定オフセット結果を返せますが、現実の地域規則が正しいかは別途確認が必要です。
• 日時文字列を丸ごと曖昧解析せず、年、月、日、時、分、秒、オフセットを分離した入力欄にします。03/04/05のような地域依存順序や、ブラウザーlocaleの自動解釈を避けます。結果も各成分を別欄で示し、コピー時に単位と符号を確認できるようにします。
• 範囲端ではオフセットを足した現地日時が1600年より前、または9999年より後に出る組合せを拒否します。入力UNIX秒だけが広い許容範囲内でも、最終通算日が範囲外なら年を推測表示しません。端の値ではオフセット0だけでなく+14時間と−14時間を含めて検査します。
• 本ページは端末の現在日時を自動取得しないため、実行した瞬間のUNIX時間を調べる時計ではありません。ログ、証明書、API値など変換したい秒や日時を明示入力します。再現性のため、元値、単位が秒かミリ秒か、固定オフセット、参照資料、変換日時を一緒に記録してください。
• 十桁のUNIX秒と十三桁のUNIXミリ秒を混同しないでください。本ページへミリ秒値を入れると範囲外になるか、意図しない遠い年月になります。元システムがmilliseconds since epochを返す場合は先に1000で割り、余りのミリ秒を別に保存します。切り捨て、四捨五入、保持のどれを採るかは用途規則に従います。
• この変換は法定期限、契約時刻、取引成立時刻、医療記録の確定を行いません。DSTの重複時刻や欠落時刻、システム独自epoch、32ビットtime_t、GPS時刻には別条件があります。重要な判断では対象システムの仕様、公式ログ、担当者の確認を組み合わせてください。
• 結果をISO 8601やRFC 3339の文字列へ組み立てる場合は、年月日の区切り、T、二桁の時分秒、Zまたは数値オフセットを明示します。本ページは数値成分の変換までを担当し、書式の省略形、週日付、年内通算日、時刻帯略称へ自動変形しません。受け渡し先が要求する書式を別に確認してください。
• UNIX時間の上限は実装ごとに異なります。いわゆる2038年問題は符号付き32ビット秒の上限に関係しますが、本ページの入力値はその範囲を越えても安全整数内で計算できます。ただし受け渡し先のデータベース、言語、ファイル形式が同じ範囲を持つとは限らないため、保存前に型と制約を照合します。
• 往復検算では、日時からUNIX秒へ変換した後、同じ固定オフセットで再び日時へ戻し、七つの入力成分が一致するか確認します。異なるオフセットで戻せば同じ瞬間の別の壁時計表示になるため、不一致とは限りません。瞬間を比べるのか、表示文字列を比べるのかを先に決めてください。
• 汎用の検算です。対象システムの正式仕様、ビット幅、時刻尺度、オフセット、丸め規則を独立に確認してください。

よくある質問