日本・米国の固定UTCオフセット時刻一覧変換

日本・米国の固定UTCオフセット時刻一覧変換

入力日時と固定UTCオフセットコードから、JST・UTC・米国標準時/夏時間コード15行を同時換算します。

入力

地理的タイムゾーンではなく固定UTCオフセットコードを選びます。

正規グレゴリオ暦の西暦年です。

1月を1、12月を12として入力します。

年月の組合せとして実在する日を入力します。

24時間制の0〜23時です。

0〜59分です。

使い方

  1. 固定オフセット時刻表の入力欄へ、元資料で確認した値と明示的な選択条件を入力します。
  2. 計算ボタンを押し、先頭行、日付またぎや周期位置など目的に関係する列を確認します。
  3. ページの対象外条件と資料確認日を読み、制度判断や自動推測の結果ではないことを確認します。
  4. 必要なら見出し付きTSVをコピーし、入力条件、使用目的、確認日と同じ記録へ保存します。

計算式・考え方

入力日の整数JDNをD、時分をm、変換元の固定オフセットをo₀分、変換先をo₁分として、UTC基準分=D×1440+m−o₀、変換先分=UTC基準分+o₁で求めます。商を日付、余りを時分へ戻します。

注意事項

  • この時刻表は地理的なタイムゾーンではなく、名前付きの固定UTCオフセットコードを変換します。JSTはUTC+09:00、ESTはUTC−05:00のように、入力したコードの差だけを使います。都市名、国名、住所からコードを推測する機能はありません。
  • 変換元コード、年、月、日、時、分を明示して計算します。現在時刻を端末時計から自動入力せず、入力欄を開いた時刻へ勝手に更新しません。会議記録やログの再現では、画面を見た時刻ではなく元資料に記載された日時を入力してください。
  • 出力はUTC、JSTと、AST、ADT、EST、EDT、CST、CDT、MST、MDT、PST、PDT、AKST、AKDT、HSTの固定15行です。同じオフセットを持つコードがあっても、略号の意味を残すため別行として表示します。
  • 末尾のSやDは標準時と夏時間のコードを区別しますが、このページは日付からどちらを採用すべきか判定しません。夏時間の開始日・終了日、州や地域の例外、過去の法改正を持つtzdbを搭載せず、選択された固定値を一年中そのまま使います。
  • 例えば日本の正午をJSTとして入力するとUTCは同日03:00になり、米国側の負のオフセットでは前日になる行があります。日付差列は入力日を0として前日を−1、翌日を1で示します。時刻だけでなく日付列も必ず一緒に確認してください。
  • ASTやCSTなどの略号は世界の別地域で異なる意味に使われる場合があります。このページのコード集合は表示されたUTC差と対にした固定契約です。相手から略号だけを受け取った場合は、UTC差、地域、標準時か夏時間かを相手に確認してから選びます。
  • 情報通信研究機構の日本標準時資料ではJSTとUTCの関係を確認できます。UTCは世界の時刻比較に使う基準であり、日本標準時はUTCより9時間進みます。本ページは標準電波や時刻同期を提供せず、入力した整数分の換算だけを行います。
  • NIST「Local Time FAQs」は米国の地域時刻と夏時間を確認するための資料名です。実際の会議、航空、金融、放送、締切では、対象地域がその日に採用する時刻を公式情報で確かめ、この固定コード表の選択へ反映してください。
  • うるう秒は時分入力に現れないため扱いません。秒を切り捨てたログ、サーバーのUTC記録、端末のローカル表示を比較するときは、元データの秒、精度、同期状態を別に保存してください。このページの一致は時計の正確さを証明しません。
  • 日付は西暦1年から9999年の正規グレゴリオ暦として整数JDNへ変換します。歴史上その地域が当時グレゴリオ暦や同じオフセットを採用していたと保証する計算ではありません。古い史料には暦法と地方時の調査が必要です。
  • 範囲端では15行すべてが西暦1〜9999年に収まる場合だけ結果を返します。一部地域だけ範囲外になる条件でも、その行を隠して残りを表示せず表全体を停止します。完全な15コード比較であることを優先した安全設計です。
  • 入力日として存在しない2月29日、4月31日、0月は拒否します。自動的に月末へ丸めると時刻記録の意味が変わるためです。エラーが出たら元資料の日付、標準時・夏時間表記、午前午後の転記を順番に見直してください。
  • 検算では、まず変換元と同じコードの行が入力日時に一致するか確認し、次にUTC行でオフセットを引いた値を確認します。最後にJSTや目的コードへ差を加え、午前0時をまたぐと日付が前後しているかを調べます。
  • 結果を連絡するときは、日時だけでなくコードとUTC差を併記してください。『米国東部10時』だけではESTかEDTか判別できない季節があります。固定換算を使ったこと、夏時間を自動判定していないことも共有すると誤解を減らせます。
  • 入力と換算はclient-onlyで、現在時刻サービス、位置情報、外部API、tzdb、ネットワーク照会を使いません。コピーした表は端末のクリップボードへ渡るため、機密性の高い予定や運用ログは共有端末へ残さず、組織の情報管理手順に従ってください。
  • 固定差と資料名は2026年7月16日に、JST、UTC、情報通信研究機構の日本標準時資料、NIST「Local Time FAQs」で再確認しました。規則変更や地域例外を自動追跡しないため、利用日と目的地の公式時刻情報を別途確認してください。
  • 予約や会議の案内へ転記するときは、主催地の年月日、時刻、コード、UTC差を一組として保存し、参加者側の地理的タイムゾーン変換は信頼できる予定管理機能でも再確認してください。固定コード表のEDT行を選んだという事実だけでは、開催地がその日に夏時間を採用する証明になりません。変更連絡では旧時刻を消すだけでなく、新旧のUTC表記と変更理由を残すと、日付またぎによる一日違いを発見しやすくなります。
  • 有界な暦参照計算です。制度上の年齢、地域時刻、歴史的紀年、法的効果は用途に合う公式資料で個別に確認してください。

よくある質問

夏時間を日付から自動判定しますか?

しません。ESTとEDTなどを固定コードとして別々に表示し、採用コードは利用者が確認します。

都市名からタイムゾーンを選べますか?

選べません。地理的tzdbではなく明示した固定UTC差だけを扱います。

現在時刻を表示しますか?

表示しません。入力した年月日時分だけを決定的に換算します。

日付が変わる場合は分かりますか?

現地日付と入力日との差を表示します。前日・翌日になった行は時刻と一緒に確認してください。

固定オフセット時刻表の入力検査、計算、結果表、コピー用TSVはclient-onlyで処理し、外部API、アップロード、サーバー保存、現在時刻の自動取得を使用しません。