最初に確認すること
ソウルの深夜直後がニューヨークでは前日の午前ということがあります。同じ瞬間に異なる日付が付いているので、勝手に1日足さないでください。予定を伝える際に時刻だけを送ると日を間違えるおそれがあります。
実際の操作手順
現地の日付と時刻には変換先ではなく変換元の現地日時を入れます。変換元の時間帯と変換先の時間帯で提供されているゾーンを選び、計算を押してください。任意のIANA名を自由入力する欄ではありません。固定時差の暗算ではなく日付を含む変換を使います。
検証した例
2026-01-15 00:30、Asia/Seoul→America/New_Yorkの実際の英語結果はJan 14, 2026, 10:30 · America/New_Yorkでした。日付は1月15日ではなく14日です。独立したPython ZoneInfoでも確認しました。結果全体をコピーし、予定を入れるアプリでも日付を確認してください。
| 入力 | 出力 |
|---|---|
2026-01-15 00:30 · Asia/Seoul | 2026-01-14 10:30 · America/New_York |
2026-01-15 12:00 · America/New_York | 2026-01-15 17:00 · UTC |
2026-07-15 12:00 · America/New_York | 2026-07-15 16:00 · UTC |
結果の確認
America/New_Yorkの2026-01-15 12:00→UTCは17:00、2026-07-15 12:00→UTCは16:00でした。検証した日付では季節のオフセットが異なります。冬の時差を夏の予定へそのまま使ったり、各国が同じ日に時計を変えると考えたりしないでください。ブラウザーのゾーンデータや将来の規則変更も関係します。
うまくいかない場合
ニューヨークの2026-03-08 02:30は存在せず、2026-11-01 01:30は2回現れます。ツールは両方を拒否し、推測しませんでした。主催者に一意の現地時刻を確認するか、確定したUTCの瞬間を使ってください。通常の結果が変なら変換元の日付・ゾーンと変換先ゾーンを再確認します。
よくある質問
前日の結果を今日に直しますか？
まず入力を確認してください。同じ瞬間でも日付は異なり得ます。
冬と夏で1時間違うのはなぜですか？
検証した日付で季節のオフセットが異なったためです。
重複する時刻を自動で選びますか？
いいえ。曖昧または存在しない現地時刻は拒否します。
制限
繰り返し予定の管理ツールではありません。提供ゾーンと対応日付だけを使い、過去・将来の結果はブラウザーの時間帯データに依存します。