Londra Çıkışı - sayfa 2

 

Evet, hepsi IMO yüzünden kafa karıştırıcı bir tasarım kararı :) Yani sunucu zamanı bir yıl boyunca bilinen herhangi bir dünya saatine bile karşılık gelmeyebilir.

Geriye dönük test sırasında özellikle GMT zamanını doğru bir şekilde belirlemek için bir yöntemim var. Bu yöntem, aracılar için işe yarıyor gibi görünüyor.

  • TZ'yi tarihsel verilerinin ortasında değiştirmiş (Alpari),
  • veya Onüç'ün belirttiği gibi kendi saat dilimlerine (FXCM) göre standart olmayan DST kullanın,

ama yaklaşım hala bana biraz tuhaf geliyor.

Diğer kaynaklardan (dukascopy) GMT tabanlı alıntıları indirmeyi ve her bir günlük en yüksek saatin saatini karşılaştırmayı içeriyordu. Geriye dönük test için sorunsuz çalışıyor, ancak şu anda saat verilerini manuel olarak indiriyorum ve yüksekleri filtreliyorum (bir Perl betiği kullanarak).

En az iki kaynaktan GMT H1 fiyat tekliflerini otomatik olarak alabildiğimde, amaçlarım için bu yaklaşımla rahat olacağım.

 
SDC :

MT4 bunu yapmak için nasıl daha yeterli hale getirilebilir? Sizi bilmem ama ben bölgesel bir tarihsel GMT denkleştirme hesaplayıcısı oluşturma görevinden kesinlikle hoşlanmazdım. Sadece hayal edebiliyor musun? Aman tanrım. Yaparsam piyasaya süreceğim hepinizin kocaman bir çek defteriniz olsa iyi olur ;)

Tarihsel bir GMT hesaplayıcısı başlı başına özellikle zor değildir (Windows işletim sistemi ihtiyacınız olan tüm verileri zaten içerir), ancak birincil sorun değildir. Sorun şu ki, komisyoncu zamanı ile GMT arasındaki mevcut ofseti belirleyebiliyorsunuz, ancak değişip değişmediğini/ne zaman değişeceğini bilmiyorsunuz. Yukarıdaki örneği kullanarak, aracının şu anda GMT+3'te olduğunu görebilirsiniz (yerel bilgisayar saatinin doğru olduğunu varsayarak...), ancak aracının geçen hafta GMT+2'de olduğunu bilmiyorsunuz.

MT4 istemci terminalinin bu bilgilere sahip olmaması çok olasıdır.

Eğer varsa , MT4 ya kendiniz işleyebileceğiniz çıplak verileri ya da "geçmişteki herhangi bir komisyoncu tarihini GMT'ye dönüştür" demenize izin veren bir işlev sağlayabilir. Bunu yaptıktan sonra, o tarihi GMT saatini Londra gibi başka bir saat dilimine dönüştürmek için bir arama tablosu (veya Windows API'si) kullanabilirsiniz. Ancak, MT4'ün bunu sizin için de yapması tercih edilir, örneğin aşağıdaki gibi bir çift fonksiyon:

datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);

datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);

 
ydrol :

Evet, hepsi IMO yüzünden kafa karıştırıcı bir tasarım kararı :)

(UTC'de sabitleme yapmama sebebinin, brokerlerin EET'de haftada beş D1 mum vererek çalışabilmeleri ve GMTZ kullanan komisyoncularda D1 ATR gibi şeylerin sistemik olarak küçümsenmesine yol açan altıncı küçük mumdan kaçınabilmeleri olduğunu varsayıyorum.)
 
gchrmt4 :
(UTC'yi sabitlememe sebebinin, brokerlerin EET'de haftada beş D1 mum vererek çalışabilmeleri ve altıncı küçük mumdan kaçınabilmeleri olduğunu varsayıyorum, bu da GMTZ kullanan komisyoncularda D1 ATR gibi şeylerin sistemik olarak küçümsenmesine yol açar.)


Tüm bunları client'a koyardım ama bu client'ı farklı yerlerde daha karmaşık hale getiriyor :) Ama en azından tüm değişkenler biliniyor.
 

Başka bir yaklaşım, bu sayfaya göre sadece 62 MT4 brokeri var mı? Bu nedenle, her bir komisyoncu ve onların zaman tanımları için (ister gerçek bir saat dilimine, isterse FXCM'nin bir kombinasyonuna dayalı olsun) bir arama tablosuna sahip olmak ve ayrıca tarihsel değişiklikleri (ala Alpari) dahil etmek çok zor olmaz.

Bu muhtemelen en sağlam yaklaşımdır ve bir komisyoncu müşterilerinin kafasını biraz daha karıştırmak istediğine her karar verdiğinde ince ayar yapılması gerekecektir :)

 

gchrmt4 :

[1] GMT+3 sunucu saatiniz, EEST'nin GMT+3 olması anlamında EEST'e karşılık gelebilir, ancak hem Wikipedia'ya hem de worldclock.com'a göre, henüz hiçbir yerde EEST'de olmamalıdır. Bu değişiklik 30 Mart'a kadar olmamalı. Kıbrıs, Yunanistan, İsrail vb. ülkelerdeki geçerli saat GMT+2'dir.

[2] Bu nedenle, muhtemelen sahip olduğunuz şey, sunucularını GMT+2'de çalıştıran, ancak Avrupa tarihleri yerine ABD tarihlerinde yaz saati uygulamasına geçen bir komisyoncudur.

[3] Bu, EET/EEST ile aynı şey değil. (Ayrıca, aracının hangi zaman ayarlarını kullandığı konusunda kullanıcıya bir tür girdi sormak zorunda kalmadan saatleri ve tarihleri otomatik olarak ayarlayan kod yazabilme açısından daha da az tahmin edilebilir.)

  1. Doğru.
  2. Doğru.
  3. EET, GMT+2'dir, ancak GMT+2 yalnızca EET değildir. Ayrıca EEST, GMT+3'tür, ancak GMT+3 yalnızca EEST değildir. Brokerimin saat dilimini EET/EEST olarak tanımlayarak, özellikle bu ileti dizisinde Londra kopuşundan bahsedildiği için, standart saatte GMT+2 ve gün ışığından yararlanma saatinde GMT+3 olduğu sonucunu çıkarmak istedim. Açıklamam biraz karışıklığa yol açtıysa özür dilerim. :)

Bu nedenle, komisyoncu GMT+3'ten GMT+4'e geçmek yerine yakın zamanda GMT+2'den GMT+3'e geçmişse, bunun anlamı, komisyoncu zamanı ile GMT arasındaki geçerli farkın şu şekilde olması gerektiğidir: ABD saati değişmeden önce geçen hafta barlara uygulamayı denediniz. Bu hafta, komisyoncunun barları Londra'nın 3 saat ötesinde. Geçen hafta 2 saat öndeydiler. (Ve 30 Mart'tan itibaren yine 2 saat ileride olacaklar.) Bu 3 saatlik ofseti alır ve geçen hafta Londra saatiyle sabah 8'de fiyatı almak için kullanırsanız, yanlış cevap alırsınız. .

Bir komisyoncu, yaz saati uygulamasına ayarlamak dışında genellikle sunucusunun saat dilimini sık sık değiştirmez. Yaz saati uygulaması için herhangi bir tarih/saat kullanabilirim (1987 (ABD) ve 1996 (AB) ile 2020 ve sonrası arasında) ve ABD ve AB için gün ışığından yararlanma saatinin başladığını ve gün ışığını hesaplayabilirim zaman tasarrufu sona erer. Bu koda sahip olduğunuzda, tek yapmanız gereken, baktığınız zaman için gün ışığından yararlanma saatine uyum sağlamak için mevcut ofseti GMT'ye ayarlamaktır.

600+ yapısında yeni olan TimeGMT() ile aracınızın mevcut GMT ofsetini hesaplarsınız. Ancak (bildiğim kadarıyla) geçmişten bir komisyoncunun saat dilimini belirleyemez. Örneğin, bir aracıya, sunucusunun saat dilimini standart saat için GMT'den standart saat için GMT+2'ye değiştirmesini sağladım. Bununla, anahtardan önceki zaman için bir ofseti sabit kodlayarak ele aldım çünkü tüm geçmiş verileri GMT+2 değil GMT idi (ve geçmişi GMT+2'yi yansıtacak şekilde değiştirmek istemedim). Bu anlamda size inanıyorum ve katılıyorum. Bir komisyoncu yalnızca saat dilimlerini değiştirmediği sürece (yaz saati uygulamasına göre ayarlamak dışında), GMT'ye göre farkı hesaplayabilmeli ve bu farkı yaz saati uygulamasına göre ayarlayabilmelisiniz.

Tek söylediğim, sadece MT4'ün kendisinden elde edilebilecek bilgilerin - broker zamanı ile GMT arasındaki mevcut farkın - pratikte "geçen Çarşamba Londra'da açılış fiyatını hesapla" gibi şeyler yapmak için yetersiz olduğu.

Seninle aynı fikirde olmadığıma inanıyorum. Aracı, gün ışığından yararlanma saatini ayarlamak dışında saat dilimlerini değiştirmediği sürece , hem geçerli saat hem de geçmiş saat için GMT'ye göre farkı belirleyebilirsiniz. Geçen hafta standart saatte, komisyoncu GMT+2 ve Londra GMT ise, o zaman sabah 8'de Londra saati, sunucu saati sabah 10'dur. Gelecek ay, yaz saati uygulaması sırasında, komisyoncu GMT+3 ve Londra GMT+1 olduğunda, 08:00 Londra saati sunucu saatinin 10:00'a karşılık gelir. Bugün, komisyoncu gün ışığından yararlanma saatinde ve Londra standart saatte olduğunda, komisyoncu GMT+3 ve Londra GMT'dir, bu nedenle sabah 8'de Londra saati sunucu saati 11'dir.

Eğer komisyoncu GMT-5 (EST) ve Londra GMT ise, Londra sabah 8'de sunucu saatiyle 3'tür.

 
gchrmt4 :

Tarihsel bir GMT hesaplayıcısı başlı başına özellikle zor değildir (Windows işletim sistemi ihtiyacınız olan tüm verileri zaten içerir), ancak birincil sorun değildir. Sorun şu ki, komisyoncu zamanı ile GMT arasındaki mevcut ofseti belirleyebiliyorsunuz, ancak değişip değişmediğini/ne zaman değişeceğini bilmiyorsunuz. Yukarıdaki örneği kullanarak, aracının şu anda GMT+3'te olduğunu görebilirsiniz (yerel bilgisayar saatinin doğru olduğunu varsayarak...), ancak aracının geçen hafta GMT+2'de olduğunu bilmiyorsunuz.

MT4 istemci terminalinin bu bilgiye sahip olmaması çok olasıdır.

Eğer varsa , MT4 ya kendiniz işleyebileceğiniz çıplak verileri ya da "geçmişteki herhangi bir komisyoncu tarihini GMT'ye dönüştür" demenize izin veren bir işlev sağlayabilir. Bunu yaptıktan sonra, o tarihi GMT saatini Londra gibi başka bir saat dilimine dönüştürmek için bir arama tablosu (veya Windows API'si) kullanabilirsiniz. Ancak, MT4'ün bunu sizin için de yapması tercih edilir, örneğin aşağıdaki gibi bir çift fonksiyon:

datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone);

datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone);


Evet DST olmasaydı zor olmazdı ama lol var... kodlaması tam bir kabus olurdu. Tarihsel anormallikler her yerde olurdu. Kullandıkları saat dilimini değiştiren bölgeler, DST'yi hiç kullanmamayı deneyen bölgeler, daha sonra DST'ye geri döndüler, DST'ye bazı yerlerde saygı duyan, diğerlerinde olmayan bölgeler, tüm dünyada dikkate alınması gereken çok fazla anormallik olurdu. ..
 
ydrol :

Başka bir yaklaşım, bu sayfaya göre sadece 62 MT4 brokeri var mı? Bu nedenle, her bir komisyoncu ve onların zaman tanımları için (ister gerçek bir saat dilimine, isterse FXCM'nin bir kombinasyonuna dayalı olsun) bir arama tablosuna sahip olmak ve ayrıca tarihsel değişiklikleri (ala Alpari) dahil etmek çok zor olmaz.

62 düşük bir tahmindir ve daha büyük brokerlerin sunucuları farklı zaman dilimlerine ayarlanmış.
 

Thirteen :

Geçen hafta standart saatte, komisyoncu GMT+2 ve Londra GMT ise,

Yalnızca MT4'ün sağladığı bilgileri kullanarak, aracının geçen hafta GMT+2'de olduğunu nasıl bilebilirsiniz?
 

Sağduyu yaklaşımı, MT4 sunucusunun her zaman GMT kullanması olacaktır, ancak bunu yapmayacaklarını biliyorsunuz.