Forex’te Londra–New York örtüşmesi neden tarihe göre değişir?

Londra ve New York’un yerel çalışma saatleri hiç değişmese bile iki şehrin örtüşme tablosu bir saat kayabilir. ABD ve Birleşik Krallık saatlerini farklı tarihlerde ileri ve geri alır. Mart ayının bir bölümünde ve ekim sonunda iki şehir arasındaki fark, olağan beş saat yerine dört saattir. Bu nedenle örtüşmenin yalnızca UTC başlangıcı veya bitişi değil, süresi de değişebilir.

Doğru yöntem, her şehir için yerel saat aralığını tanımlamak ve kesişimi incelenen tarihe göre hesaplamaktır. Burada kullanılan, iki şehirde de yerel 08:00–17:00 varsayımıyla kesişim, her ikisi de standart saatte veya her ikisi de yaz saatindeyken dört saattir. New York yaz saatinde, Londra standart saatteyken beş saate çıkar. Bu bir saat hesabıdır; beş saat boyunca elverişli işlem koşulları bulunacağını göstermez.

Örtüşmeyi aramadan önce iki aralığı tanımlayın

Spot döviz piyasası tezgâh üstüdür; işlemler farklı işlem sağlayıcıları ve platformlar arasında dağılır. Londra seansı ifadesi, tek bir resmî açılış zili, zorunlu bir kapanış saati veya bütün hesaplar için aynı erişim anlamına gelmez. Sağlayıcınız ürün bazında işlem saatleri, bakım araları ve tatil düzenlemeleri uygulayabilir.

Tekrarlanabilir bir örnek için Londra çalışma aralığını Londra yerel saatiyle 08:00–17:00, New York aralığını New York yerel saatiyle 08:00–17:00 kabul edelim. İkisi de aynı yerel takvim tarihine aittir; başlangıç dahildir, bitiş anı değildir. Bunlar analiz için seçilmiş girdilerdir, herhangi bir sağlayıcının veya işlem yerinin resmî çalışma saatleri değildir.

Saat bilgisini tarih ve şehirle birlikte tutun. Londra’da 08:00 ile New York’ta 08:00 aynı an değildir. EST, UTC−5 demektir ve yıl boyunca New York yerel saati yerine kullanılamaz; EDT, UTC−4’tür. Londra bu dönüşümlerde UTC’ye eşdeğer GMT’yi veya UTC+1 olan BST’yi kullanır. Örneklerde Pekin saati UTC+8’dir.

ABD ve Birleşik Krallık için gerçek saat değişim tarihlerini kullanın

New York, 2026’da ABD yaz saati takvimine göre 8 Mart’ta yaz saatine geçer ve 1 Kasım’da standart saate döner; değişimler yerel 02:00’de gerçekleşir. Birleşik Krallık’ta saatler 29 Mart’ta ileri, 25 Ekim’de geri alınır. Mevcut ABD kuralı martın ikinci, kasımın ilk pazarını; Birleşik Krallık kuralı mart ve ekimin son pazarını esas alır.

Bu nedenle 2026’da 9–27 Mart arasındaki hafta içi örneklerinde Londra GMT, New York EDT kullanır. Aynı birleşim 26–30 Ekim arasında tekrar görülür; Londra dört saat ileridedir. GMT/EST veya BST/EDT birleşimlerinde fark beş saattir. Başka yıllar için uygulanacak tarihleri yeniden kontrol edin; bu dört tarihi kalıcı takvim olarak kullanmayın.

Yerel saatin bir saat ileri alınması, aynı yerel çalışma saatinin UTC’de bir saat erkene gelmesini sağlar; UTC’nin kendisi değişmez. İlkbaharda önce New York ileri alır. Sonbaharda önce Londra geri alır. Bu sıra farkı, örtüşmenin bir sınırı değişirken diğerinin neden sabit kalabildiğini açıklar.

İki aralığı UTC’ye çevirip kesişimi bulun

Her sınır için UTC saati = yerel saat − şehrin o tarihteki UTC farkı kuralını uygulayın. Tüm sınırlar UTC’ye çevrildikten sonra kesişim, daha geç açılışta başlar ve daha erken kapanışta biter. Süresi, sıfır ile bitiş eksi başlangıcın büyük olanıdır. Aralık gece yarısını geçiyorsa yalnız saat rakamlarını değil, tam tarih ve saatleri karşılaştırın.

Örneğin 9 Mart’ta Londra için varsayılan aralık 08:00–17:00 UTC, New York için 12:00–21:00 UTC olur. Daha geç başlangıç 12:00, daha erken bitiş 17:00’dir: beş saat. 30 Mart’ta Londra 07:00–16:00 UTC’ye geçerken New York 12:00–21:00 UTC’de kalır ve kesişim dört saate iner.

İlk sütun, Londra ve New York’un 2026’daki ortak yerel takvim tarihini gösterir. Son sütunda Pekin’de ertesi güne geçen bitiş tarihi açıkça yazılmıştır. Örneğin 23 Ekim 16:00 UTC, Pekin’de 24 Ekim 00:00’dır; 23 Ekim’in başlangıcı değildir. Aralıklar başlangıcı içerir, bitişi içermez: tam 16:00 UTC’deki olay, 23 Ekim örtüşmesinin dışındadır.

2 Kasım örneği dahil bütün sonuçlar, belirtilen kurallar ve varsayımlarla yapılan takvim hesaplarıdır; o tarihlerdeki gerçek işlemlerin gözlemi değildir. 23 Ekim’den 26 Ekim’e geçerken UTC başlangıcı sabit kalır, bitiş bir saat ileri kayar. 26 Ekim’den 2 Kasım’a geçerken bitiş sabit kalır, başlangıç bir saat ileri kayar. Bütün zaman bloğunu bir saat taşımak, iki geçişi birden açıklamaz.

Sabit dört saatlik filtre yanlış saati alıp doğru saati kaçırabilir

Bir araştırma kodunun yaz aylarındaki ayarını koruyarak her gün 12:00 UTC dahil, 16:00 UTC hariç tüm kayıtları aldığını varsayalım. Bu sabit filtreyi tarihe özgü kesişimle karşılaştırın. Yanlış alınan saatler, varsayılan örtüşmenin dışındadır; ürünün işlem saatleri dışında olmaları gerekmez.

2 Kasım’da hem sabit filtre hem doğru aralık dört saat sürer, fakat ortak bölüm yalnız üç saattir. Filtre 12:00–13:00’ı yanlış alır, 16:00–17:00’ı atlar. Sürenin veya satır sayısının değişmemesi, fiyat örnekleminin aynı olduğunu göstermez. Her dakika başlangıcında bir kayıt varsa ve veri eksiksizse iki filtrede de 240 satır bulunur; 180’i ortaktır, her birinde diğerinde bulunmayan 60 satır vardır. Eksik veriler için ayrıca sayım yapılmalıdır.

Gün içi geriye dönük testlerde spread, fiyat aralığı veya getiri karşılaştırmadan önce zaman damgalarının hangi aralığa girdiğini yeniden belirleyin. Bir sınırı aşan mum, yalnızca zaman etiketi içeride diye bütünüyle aralığın içinde sayılmaz. Olay zamanlarını mı, bütünüyle içeride kalan mumları mı yoksa başka tanımlı bir kuralı mı kullandığınızı belirtin; tam ayrım gerekiyorsa daha ayrıntılı veri kullanın. Günlük mumların oluşturulması ayrı bir konudur; bunun için kapanış saatinin forex günlük mumlarını nasıl değiştirdiği ayrıca incelenmelidir. Grafiğin gösterim saat dilimini değiştirmek bu hesapları kendiliğinden düzeltmez.

Saat etkisini doğrulayın, daha iyi gerçekleşme varsaymayın

İki yerel çalışma aralığı değişmiyor, resmî saat farkları beklendiği gibi değişiyor ve kaydedilmiş zaman damgaları yeni UTC sınırlarını veriyorsa saat değişimi açıklaması desteklenir. Başlangıcın hemen öncesini, başlangıcın kendisini ve dışlanan bitişi sınayın. Sonuçlar uyuşmuyorsa seans etiketine güvenmeden önce kayıtlı saat dilimini, sunucu farkını veya tarihin anlamını araştırın.

Hesabın uygulanabilirliği girdilere bağlıdır. Tatil, kısaltılmış çalışma günü, başka bir sağlayıcı takvimi veya üründeki bir işlem arası, 08:00–17:00’ı gerçek faaliyet için uygunsuz bir temsil haline getirebilir. Ekonomik veri açıklaması kendi takvimindeki saat esasına bağlıdır; örtüşme etiketi değişti diye kaydırılmaz. Ürünün işleme açık olması, takas takvimi ve iki şehrin ortak aralığı ayrı kontrollerdir.

Doğru çevrilmiş bir aralık bile dar spread, yeterli miktar veya emrin gerçekleşmesini garanti etmez. Daha çok potansiyel katılımcı, belirli bir hesabın alabileceği fiyatı belirlemez; oynak bir olay aralık içindeki koşulları da değiştirebilir. Aynı döviz çifti, fiyat kaynağı, alış ve satış fiyatlarının zaman damgaları, planlanan miktar ve gerçek işlem kayıtlarını inceleyin. Büyük bir mum, işlem yapılabilir likiditenin ölçüsü değildir.

Bu aralığın emir gerçekleşmesini iyileştirip iyileştirmediğini değerlendirmek için tanımlı bir örneklemde aynı büyüklükte emirleri ve aynı esastaki fiyatları karşılaştırın; veri açıklaması günlerini, tatilleri ve eksik gözlemleri ayırın. Saat hesabı hangi kayıtların aralığa ait olduğunu söyler; gözlemler gerçekleşme kalitesini sınar. Bunlar olmadan zaman aralığı tek başına avantaj kanıtlamaz.

Tarihe duyarlı ve denetlenebilir bir takvim oluşturun

Önce analiz tarihini, döviz çiftini, ürünü, varsayılan yerel aralıkları ve adlandırılmış saat dilimlerini kaydedin. Yazılımda kalıcı olarak dört veya beş saat çıkarmak yerine, güncel saat dilimi verileriyle Europe/London ve America/New_York gibi kimlikler kullanın. Özgün zaman damgalarını ve veri ya da sunucu saat dilimini koruyun; üzerlerine saat dilimi belirtilmemiş yerel saatler yazmayın.

Ardından iki aralığı UTC’ye çevirin, kesişimi hesaplayın ve sonuçtaki tam tarih-saatleri gösterimde kullanılan saat dilimine dönüştürün. Başlangıç tarihi, bitiş tarihi, saat farkları ve süreyi birlikte saklayın. İlk tablodaki altı tarih için süreler sırasıyla 4, 5, 4, 4, 5 ve 4 saat olmalıdır. Bitişin dışlandığını ve Pekin’de ertesi gün tarihini sınayan kontroller ekleyin.

Sonra sağlayıcının gerçek saatlerini ve olağan dışı kapanışları kontrol edin; ekonomik takvimi ve veri zaman damgalarını ayrı ayrı hizalayın. Bir program sabit UTC olarak tanımlanmışsa bu tanımı koruyun: farklı bir girdidir, sessizce düzeltilmesi gereken bir hata değildir. İleride yerel bir sınır, saat değişiminde tekrarlanan veya hiç oluşmayan bir saate denk gelirse belirsizliği nasıl çözeceğinizi tanımlayın. Buradaki hafta içi gündüz örnekleri bu sorunu önler.

Son olarak saat kuralları veya seçilen çalışma aralıkları değiştiğinde takvimi yeniden üretin. Varsayımları sonuçla birlikte tutun. Güvenilir çıktı, Londra ile New York’un her gün ve yıl boyunca aynı saatlerde örtüştüğünü söylemek değil; tarihi, sınırları ve kapsamı belli, sınanabilir bir aralıktır.