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

使い方

1. 1600〜9999年のGregorian年月日と、24時間制の時分秒を個別に入力します。
2. その現地日時へ適用する固定UTCオフセットをlocal−UTCの分で入力します。
3. 計算した整数UNIX秒を確認し、元日時、オフセット、秒単位であることを一緒に保存します。

計算式・考え方

S=gregorian_serial_day(年月日)とし、UNIX秒=(S−135140)×86400+3600×時+60×分+秒−60×固定オフセット分です。offset=local−UTCなのでUTCへ戻すときは引きます。

注意事項

• 現地年月日の通算日Sと時分秒からT=(S−135140)×86400+3600×時+60×分+秒を作り、UNIX秒U=T−60Oとします。Oはlocal−UTCなので、UTCへ戻す方向では引き算です。各入力が整数で実在日であることを先に確認します。
• 既定値1970-01-01 09:00:00、O=540はU=0です。1969-12-31 23:59:59、O=0は−1です。日付がepochより前でも符号を保ち、絶対値だけを返しません。2000-02-29も正常例として往復できることを検査します。
• 時は0〜23、分と秒は0〜59に限定します。24:00:00を翌日へ自動繰り上げず、60秒を1分へ正規化しません。入力欄の誤りと意図的な正規化を区別するためで、翌日0時を表したい場合は年月日を実際の翌日へ変更します。
• 日付はGregorianの実在性を三項まとめて検査します。月13、4月31日、1900年2月29日は各欄が数値範囲内に見える場合でも組合せとして拒否します。異常表示は年・月・日の三欄へ関連付け、どれか一つを勝手に修正しません。
• 固定オフセットを変えると同じ壁時計表示が指すUTC瞬間は変わります。例えば09:00を+540で読む場合と+0で読む場合は九時間異なります。ログの表示からUNIX秒を復元するときは、画面に付随するオフセットやシステム設定を確認し、不明な差を現在地から推測しないでください。
• 入力日が月末やうるう日の場合でも、通算日へ変えてからepochとの差を取るため、月ごとの秒数を手で足す必要はありません。ただし暦は先発Gregorianへ固定しており、歴史上その地域で当時使われた暦法への変換ではありません。古文書の日付や改暦日の調査には専用の暦資料を使用してください。
• 生成したUNIX秒をAPIへ送る前に、そのAPIが秒、ミリ秒、マイクロ秒、ナノ秒のどれを要求するか確認します。例えば秒0を千倍しても0のままで単位間違いを発見できないため、epochから離れた既知日時でも試験します。整数文字列として渡すか数値型で渡すかも受け渡し仕様に従ってください。
• 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秒へ変換した後、同じ固定オフセットで再び日時へ戻し、七つの入力成分が一致するか確認します。異なるオフセットで戻せば同じ瞬間の別の壁時計表示になるため、不一致とは限りません。瞬間を比べるのか、表示文字列を比べるのかを先に決めてください。
• 汎用の検算です。対象システムの正式仕様、ビット幅、時刻尺度、オフセット、丸め規則を独立に確認してください。

よくある質問