日付と時刻

タイムゾーン変換同じ瞬間を、それぞれの現地時刻へ

変換元の日時と地域を指定し、変換先のIANA識別子を1行ずつ入力してください。

タイムゾーン変換

変換元の時刻

YYYY-MM-DDTHH:mm[:ss]形式。Tの代わりに空白も使えます。Z、オフセット、小数秒は付けません。

UTCまたはAsia/TokyoなどのIANA識別子を入力します。変換元を変えると同じ時計表示を別の地域の時刻として解釈します。

1行に1識別子。最大20物理行、2,000文字。空行は無視し、同じ識別子はまとめます。

地域別の比較

変換元の時刻を入力するか、サンプルを読み込んでください。

入力した日付はこのブラウザー内で処理され、サーバーには送信されません。

設定

時刻データと実行環境

エンジン:@js-temporal/polyfill 0.5.1とブラウザーのIntlデータ。ブラウザーはタイムゾーンデータベースの版を公開しません。将来の規則は変更される場合があります。

ブラウザーのタイムゾーン: 取得できません

入力が変わりました。コピーや保存の前に再計算してください。

タイムゾーン変換は、海外から届いた打ち合わせ時刻や公開予定を日本のカレンダーに記入するときに使えます。「いつも何時間差」と覚えていても、各国のサマータイム開始日が違う週にはずれることがあります。

日付も含めて確認しましょう。東京では翌日でもニューヨークでは前日のことがあり、時計の数字だけを転記すると予定日を取り違えます。

タイムゾーン変換で確認できること

時計だけでなく日付も比較

タイムゾーン変換では各地域の日時とUTCオフセットを一緒に表示します。変換元との差は別の欄で示すため、UTCからのずれと都市間の時差を混同せずに予定を確認できます。

一つの瞬間から、異なる時刻と日付を示す三つのカードにつながる図。

秋に二度現れる時刻を区別

2024年11月3日のニューヨークでは01:30が二度あります。候補は05:30Zと06:30Zです。初期設定では変換を止め、どちらの瞬間かを選んでから各地域の結果を作ります。

一つの現地時刻が二つの瞬間に分岐し、一方が選ばれている図。

変換元と重複時刻の確認手順

01

JSTは地域名で指定

UTC・JST換算ではUTCとAsia/Tokyoを使います。端末のゾーンを使う操作はブラウザー設定を読み取ります。変換元の変更は時計の数字を保って解釈し直すため、プレビューで意味を確認してください。

02

存在しない時刻は選び直す

1回目と2回目の選択肢は重複時刻専用です。春に飛ばされた時間帯を入力した場合、どちらを選んでもエラーになります。元の予定や記録にある日時を確認して修正します。

03

結果が更新されてから保存

自動変換は編集後350ms待ちます。無効にすると変換ボタンとCtrl/Cmd + Enterが使えます。変更直後はコピーできません。サンプルや消去は適用前に確認でき、元に戻すと結果も復元されます。

指定日の規則で時差計算

夏時間の切替日も考慮

2024年3月20日のニューヨーク09:00はロンドン13:00です。米国だけが先に夏時間へ移った時期なので、普段の5時間ではなく4時間の差になります。

複数地域を入力順に表示

ロンドン、ニューヨーク、東京を初期表示します。対象は行を追加・削除して変更でき、最初に現れた順で結果を並べます。不正な識別子があると行番号を示して全体の変換を止めます。

二つの基準を分けて表示

UTCオフセットはUTCを基準にした値、変換元との時差は対象地域のオフセットから変換元のオフセットを引いた値です。日付差はそれぞれのカレンダー上の日付を比較します。

30分や45分のずれも保持

Asia/Kathmanduには45分の成分があり、Australia/Lord_Howeでは30分単位の切替があります。古いデータに秒単位のオフセットが含まれる場合も、整数時間に丸めず表示します。

受け付ける形式と扱わない用途

日時は秒までの壁時計表記
YYYY-MM-DDTHH:mm[:ss]を使い、Tを空白に置き換えることもできます。秒の省略は00です。年は0001~9999で、UTCと変換先も同範囲が必要です。日付だけ、小数秒、Zや数値偏移、うるう秒、24:00は受け付けません。
略称から地域を推測しない
UTCまたは/を含む対応IANA識別子を指定します。CST、EST、ISTや+08:00の単独指定は拒否します。Etc/GMT+5はIANAの符号規則どおりに扱い、異なる名前の別名は別行に残します。
欠けた時間を補正しない
時計が進んで存在しなくなった時刻は自動で前後へ移動しません。欠ける範囲は1時間とは限らず、30分や丸一日の場合もあります。オフセットだけから夏時間中かどうかを推定する表示はありません。
変換先リストの上限
最大20物理行、2,000文字です。空行も行数に含まれますが結果には出しません。同じ識別子は大文字小文字を区別せずまとめます。都市の日本語名検索やファイルの一括読み込みはありません。
ブラウザーが持つ規則を使用
データベースの版は取得できません。表示するpolyfillの版は計算エンジンの版で、IANAデータの版ではありません。将来の制度変更もあり得ます。会議のおすすめ時刻、勤務時間、ICS招待、履歴保存や共有URLは生成しません。

タイムゾーン変換のよくある質問

サマータイム(夏時間)の期間でも時差は正しく計算されますか?

指定日のIANA規則をブラウザーから読み取って計算します。変換元の重複時刻は明示的な選択が必要で、存在しない時刻はエラーです。将来の規則が変わった場合は、ブラウザー側のデータ更新状況にも左右されます。

UTC・GMTと日本時間(JST)の変換にも使えますか?

はい。変換元をUTC、変換先をAsia/Tokyoにすれば日本時間になります。逆方向は二つの欄を明示的に入れ替えてください。JSTやGMTという略称の解釈には頼らず、UTCと地域識別子を使います。

今の時刻ではなく、未来の日時も変換できますか?

はい。初期値は固定したサンプルで、現在時刻への追従はありません。イベントの日付を入力すれば、その日付に対する規則で計算します。まだ決まっていない将来の制度変更を予測する機能ではありません。

都市を複数選べますか?

変換先は1行ずつ追加して比較できます。20物理行までで、同じ識別子は一度だけ表示します。都市名ではなくEurope/LondonやAsia/TokyoなどのIANA識別子を指定してください。

日付をまたぐ場合は分かりますか?

各結果に完全な日付と、変換元との日付差を表示します。負の値は前の日付、正の値は後の日付です。日付変更線を挟むUTC−12とUTC+14では、同じ瞬間でも2日の差になることがあります。

結果について確認したいことがありますか?

次の予定も日付ごと確認

タイムゾーン変換の結果を予定表へ転記するときは、時刻だけでなく日付と地域も残しましょう。UTCの瞬間を添えれば相手も照合できます。