ロンドンとニューヨークのFX重複時間はなぜずれる？取引日ごとの計算方法

ロンドンもニューヨークも現地の業務時間を変えていないのに、両都市が重なる時間帯は1時間ずれることがあります。米国と英国では夏時間への切り替え日が異なるためです。3月の一部と10月末には、通常5時間の時差が4時間になります。その結果、UTCでの開始・終了時刻だけでなく、重なる時間の長さも変わります。

必要なのは、各都市の現地時間で対象区間を定義し、分析する日付ごとに共通部分を求めることです。ここでは両都市とも08:00〜17:00と仮定します。両方が標準時、または両方が夏時間なら重複は4時間。ニューヨークが夏時間、ロンドンが標準時の期間は5時間です。これは時刻計算の結果であって、5時間にわたり有利な取引条件が続くという意味ではありません。

「ロンドン時間」の名称より先に対象区間を決める

現物外国為替は店頭市場で、取引は複数のディーラーや取引の場に分散しています。「ロンドンセッション」という呼び方だけで、公式な始業ベル、統一された終了時刻、すべての口座での取引可否が決まるわけではありません。商品ごとに取引時間、メンテナンス、祝日の扱いが異なることがあります。

再計算できる例として、ロンドンの対象時間を現地08:00〜17:00、ニューヨークも現地08:00〜17:00とします。両都市で同じ暦日を使い、開始時刻を含み、終了時刻は含めません。分析用に選んだ条件であり、特定業者や取引施設の公式営業時間を示すものではありません。

時刻には都市と日付を付けます。ロンドン08:00とニューヨーク08:00は同じ瞬間ではありません。ESTはUTC−5、EDTはUTC−4なので、ESTを通年のニューヨーク時間として使うのは誤りです。ロンドンのGMTは今回の換算ではUTCと同じで、BSTはUTC+1。以下の北京時間はすべてUTC+8です。

米英それぞれの切り替え日を確認する

2026年の米国の夏時間は3月8日に始まり、11月1日に終わり、切り替えは現地02:00です。英国は3月29日に時計を進め、10月25日に戻します。現在の米国の規則は3月第2日曜日と11月第1日曜日、英国は3月と10月の最終日曜日です。

したがって、2026年3月9日〜27日の平日はロンドンがGMT、ニューヨークがEDTです。同じ組み合わせが10月26日〜30日にも現れ、この期間はロンドンが4時間先になります。GMTとEST、またはBSTとEDTの組み合わせでは時差は5時間です。別の年を扱う際は日付を再確認し、2026年の日付を固定設定にしないでください。

現地の時計が1時間進むと、同じ現地業務時刻はUTC上では1時間早くなります。UTC自体が動くわけではありません。春はニューヨークが先に進め、秋はロンドンが先に戻すため、重複区間の片側だけが動くことがあります。

両区間をUTCに変換してから共通部分を求める

各端点を「UTC時刻＝現地時刻−その都市・日付のUTCオフセット」で換算します。開始は二つの開始時刻のうち遅い方、終了は二つの終了時刻のうち早い方です。長さは終了−開始とゼロの大きい方を取ります。日付をまたぐ区間では、時計表示だけでなく完全な日時で比較する必要があります。

3月9日なら、ロンドンの仮定区間はUTC08:00〜17:00、ニューヨークは12:00〜21:00です。遅い開始12:00から早い終了17:00まで、共通部分は5時間。3月30日はロンドンが07:00〜16:00となり、ニューヨークは12:00〜21:00のままなので、4時間に短くなります。

左端の日付はすべて2026年のロンドン・ニューヨークの暦日です。北京時間では終了が翌日になるため、右端には終了日も明記しています。例えば10月23日16:00 UTCは北京の10月24日00:00であり、10月23日午前0時ではありません。終了時刻を含まないので、16:00 UTCちょうどの出来事は10月23日の対象区間外です。

11月2日を含め、表は明記した条件による暦の計算であり、その日の実際の売買状況を観測したものではありません。秋の変化を見ると、10月23日から26日はUTCの開始が同じで終了だけが1時間遅くなり、10月26日から11月2日は終了が同じで開始だけが1時間遅くなります。区間全体を1時間平行移動する方法では両方を説明できません。

固定4時間のフィルターでも、余分な1時間と欠ける1時間が生じる

夏季に合わせた研究用スクリプトが、毎日12:00 UTC以上16:00 UTC未満の観測を採用するとします。日付別の正しい共通部分と比較すると、余分に含めた時間と除外してしまった時間が分かります。表の「余分」は仮定した重複区間の外という意味で、商品自体が取引不能という意味ではありません。

11月2日は、固定フィルターも正しい区間も4時間ですが、共通するのは3時間だけです。12:00〜13:00を余分に含め、16:00〜17:00を取りこぼします。行数や合計時間が同じでも、価格サンプルは一致しません。各分の開始時刻に1件ずつ欠損なく記録されていれば、双方240件、共通180件、片方だけの記録は各60件です。実データの欠損は別途確認します。

日中のバックテストでは、スプレッド、値幅、リターンを比較する前に、各タイムスタンプが対象区間に入るかを再判定します。境界をまたぐ足は、そのラベルが区間内というだけで足全体を含められません。イベント時刻で選ぶのか、完全に収まる足だけか、別の明示したルールかを決め、厳密な分割には細かいデータを使います。日足の作成は別の問題で、日足の区切り時刻によってFXチャートが変わる理由も参考になります。表示タイムゾーンの変更だけでは、どちらの計算も自動修正されません。

時刻の説明が正しくても、約定条件の改善は別問題

両都市の現地スケジュールが変わらず、公式なオフセットが規則どおりに変化し、記録時刻から新しいUTC境界を再現できれば、時計の切り替えによる差と判断する根拠になります。開始直前、開始ちょうど、含めない終了ちょうどを確認してください。合わなければ、保存時のタイムゾーン、サーバーのオフセット、日付の解釈を先に調べます。

算出した区間が適切かどうかは入力次第です。祝日、短縮営業、業者独自の時間帯、商品休止があれば、08:00〜17:00が実態を表さない場合があります。経済指標の発表時刻はそのカレンダー自身の時刻基準に従い、重複区間が動いたからといって一緒にずらしません。商品が取引可能か、決済日が適切か、両都市の区間が重なるかは個別に確認します。

正確な時刻換算も、狭いスプレッド、十分な数量、注文の約定を保証しません。参加者が多い可能性だけで、特定口座に提示される価格は決まりませんし、イベント時の変動で区間内の条件も変わります。同じ通貨ペア、価格提供元、売値・買値の時刻、予定数量、実際の約定記録を調べます。大きなローソク足は、実行可能な流動性の測定値ではありません。

この時間帯で執行が改善するかを知りたいなら、範囲を定めたサンプルで同数量の注文と同条件の価格を比較し、イベント日、祝日、欠損を区別します。時刻計算が確かめるのは区間への所属であり、執行品質を検証するのは観測データです。後者がなければ時間帯だけで優位性を主張できません。

日付に対応し、検証できるスケジュールを作る

まず分析日、通貨ペアと商品、仮定する各都市の区間、タイムゾーン名を記録します。ソフトウェアでは最新の時刻規則とEurope/London、America/New_Yorkのような日付対応の識別子を使い、常に4時間や5時間を引く処理を避けます。元のタイムスタンプとデータやサーバーのタイムゾーンを残し、タイムゾーンを明示しない現地時刻で上書きしないようにします。

次に両区間をUTCに変換し、共通部分を求め、その完全な日時を表示用のタイムゾーンへ換算します。開始日、終了日、オフセット、長さを一緒に保存します。第1表の6日間では長さが順に4、5、4、4、5、4時間になること、終了端点が除外されること、北京の終了日が翌日になることをテストします。

提供者の実際の取引時間と臨時休止を確認し、経済カレンダーとデータの時刻も別々に合わせます。最初から固定UTCで定義された予定なら、その定義を維持します。固定現地時間とは別の入力であり、勝手に修正する対象ではありません。将来、選んだ境界が時計切り替えの重複・欠落する1時間に入る場合は、曖昧さの処理を定義します。ここでの平日日中の例にはその問題はありません。

時計の規則か対象業務区間が変わったら、スケジュールを作り直し、前提を結果と一緒に残します。信頼できる成果は、日付と適用範囲が明確な検証可能な区間です。ロンドンとニューヨークは一年中同じ時刻に重なる、という固定的な説明ではありません。