Londra Çıkışı

 

Sevgili forum üyeleri,

Birkaç haftadan beri MQL4 ile ilerlemeye çalışıyorum ama ne zor! Zaten bir uzman olacağımı umuyordum! ama değilim ve biraz yardım almayı umuyorum.

Londra açılış oturumu için bir uzman danışman oluşturmaya çalışıyorum. Uzman danışmanımın Londra açılmadan önce 5 barın en yüksek ve en düşük değerini hesaplamasını ve ardından en yüksek ve en düşük değerini hesaplamasını istiyorum.

Bu işlev için, aralığı hesaplamak için iHigh işlevinin yüksek ve iLow işlevinin düşük değerlerini kullanmam gerektiğini varsayıyorum. Ancak bu aralık daha sonra gün içinde değişecektir. Bu aralığın yüksek ve düşük değerlerinin statik olmasını ve değişken olmamasını istiyorum.

Herhangi bir fikri olan var mı?

Şimdiden teşekkürler!

 
Nour :

Sevgili forum üyeleri,

Birkaç haftadan beri MQL4 ile ilerlemeye çalışıyorum ama ne zor! Zaten bir uzman olacağımı umuyordum! ama değilim ve biraz yardım almayı umuyorum.

Londra açılış oturumu için bir uzman danışman oluşturmaya çalışıyorum. Uzman danışmanımın Londra açılmadan önce 5 barın en yüksek ve en düşük değerini hesaplamasını ve ardından en yüksek ve en düşük değerini hesaplamasını istiyorum.

Bu işlev için, aralığı hesaplamak için iHigh işlevinin yüksek ve iLow işlevinin düşük değerlerini kullanmam gerektiğini varsayıyorum. Ancak bu aralık daha sonra gün içinde değişecektir. Bu aralığın yüksek ve düşük değerlerinin statik olmasını ve değişken olmamasını istiyorum.

Herhangi bir fikri olan var mı?

Şimdiden teşekkürler!


london open'ın başladığı barı nasıl buluyorsunuz...

nasıl yaptığını göster

 

Bu da başka bir sorun, artık Londra'nın açıldığı barı nasıl bulacağımı bilmiyorum...

MQL4 için hala oldukça yeniyim

 

... bir şeyi mi kaçırıyorum, yoksa MQL4'te yerleşik olan tarih/saat işlevleri bu tür şeyler için hala yetersiz mi?

İki konu:

* Aracı sunucusu ile GMT arasındaki ofseti güvenilir bir şekilde alamazsınız çünkü (a) gün ışığından yararlanma ile değişebilir ve (b) bir ofseti hesaplamak için TimeCurrent() ile TimeGMT() arasındaki herhangi bir karşılaştırma hafta sonlarında başarısız olur.

* Piyasa açıkken mevcut ofseti alabilmenize rağmen, GMT saatini Londra gibi başka bir saat dilimine çevirmenin yerleşik bir yolu yoktur.

Başka bir deyişle: (a) aracının sunucusunun CET'de çalıştığını ve bu nedenle (b) Londra saatleri, MT4 tarafından bildirilen zamanın 1 saat gerisinde olduğunu belirlemenin yerleşik bir yolu yoktur.

 

Nour :

Bu da başka bir sorun, artık Londra'nın açıldığı barı nasıl bulacağımı bilmiyorum...

MQL4 için hala oldukça yeniyim

https://docs.mql4.com/series/ibarshift
 
gchrmt4 :

... bir şeyi mi kaçırıyorum, yoksa MQL4'te yerleşik olan tarih/saat işlevleri bu tür şeyler için hala yetersiz mi?

İki konu:

* Aracı sunucusu ile GMT arasındaki ofseti güvenilir bir şekilde alamazsınız çünkü (a) gün ışığından yararlanma ile değişebilir ve (b) bir ofseti hesaplamak için TimeCurrent() ile TimeGMT() arasındaki herhangi bir karşılaştırma hafta sonlarında başarısız olur.

* Piyasa açıkken mevcut ofseti alabilmenize rağmen, GMT saatini Londra gibi başka bir saat dilimine çevirmenin yerleşik bir yolu yoktur.

Başka bir deyişle: (a) aracının sunucusunun CET'de çalıştığını ve bu nedenle (b) Londra saatleri, MT4 tarafından bildirilen zamanın 1 saat gerisinde olduğunu belirlemenin yerleşik bir yolu yoktur.


TimeGMT() 'nin Yaz Saati Uygulaması ile değişmediği görülüyor. Örneğin, ABD'de yaşıyorum, dolayısıyla şu anda yerel saat dilimim EDT. Aracımın MT4 sunucusu şu anda EEST. Şimdi aşağıdaki kodu ve çıktısını düşünün:

   Print ( "1. GMT = " , TimeToString ( TimeGMT ()));
   Print ( "2. Local Time (EDT) = " , TimeToString ( TimeLocal ()));
   Print ( "3. Daylight Saving Adjustment: " , TimeDaylightSavings ()/ 3600 );
   Print ( "4. GMTOffset for TimeLocal = " , TimeGMTOffset ()/ 3600 );
   Print ( "5. Server Time (EEST) = " , TimeToString ( TimeCurrent ()));
   
   int local = ( TimeLocal () - TimeGMT ()) / 3600 ;
   int server = MathRound (( TimeCurrent () - TimeGMT ()) / 3600.0 );
   string prt = "TimeLocal is " ;
   if (local > 0 )
      prt = StringConcatenate (prt, "GMT+" , MathAbs (local));
   else if (local < 0 )
      prt = StringConcatenate (prt, "GMT-" , MathAbs (local));
   else
      prt = StringConcatenate (prt, "GMT" );
      
   prt = StringConcatenate (prt, " and TimeCurrent is " );
   if (server > 0 )
      prt = StringConcatenate (prt, "GMT+" , MathAbs (server));
   else if (local < 0 )
      prt = StringConcatenate (prt, "GMT-" , MathAbs (server));
   else
      prt = StringConcatenate (prt, "GMT" );
    
   Print (prt);

17:52:28 Expert TestEA-1 EURUSD,H1: başarıyla yüklendi

17:52:28 TestEA-1 EURUSD,H1: 1. GMT = 2014.03.11 21:52

17:52:28 TestEA-1 EURUSD,H1: 2. Yerel Saat (EDT) = 2014.03.11 17:52

17:52:28 TestEA-1 EURUSD,H1: 3. Gün Işığından Yararlanma Ayarı: -1

17:52:28 TestEA-1 EURUSD,H1: 4. TimeLocal için GMTOffset = 4

17:52:28 TestEA-1 EURUSD,H1: 5. Sunucu Saati (EEST) = 2014.03.12 00:52

17:52:28 TestEA-1 EURUSD,H1: TimeLocal GMT-4 ve TimeCurrent GMT+3

Yukarıdaki GMT saatini Londra'nınkiyle kontrol ettim ve aynıydı (Londra Mart ayının sonuna kadar BST'ye geçmiyor). Bu nedenle, TimeGMT() öğesinin yerel Yaz Saati Uygulaması ayarlaması eklemeden GMT'yi döndürdüğüne inanıyorum. EDT , UTC-4 ve EEST , UTC+3 olarak tanımlanır.

Ayrıca, ABD veya AB için Yaz Saati Uygulamasının ne zaman başlayıp bittiğini belirlemeniz gerekiyorsa, bu işlevlere bakın .

 
Thirteen :

Yukarıdaki GMT saatini Londra'nınkiyle kontrol ettim [...]

Neredeyse kesin olarak bildiğiniz gibi... sorunlardan biri, komisyoncu saati ile GMT arasındaki farkın (a) yaz saati uygulamasına göre değişip değişmeyeceği ve (b) değişken olup olmadığı esasına göre belirlenemeyeceğidir. MT4'ün sağladığı bilgiler. Bu işlevlere ayrıntılı olarak bakmadım, ancak yalnızca MT4'ün sağladığı bilgilere dayanarak böyle bir hesaplama yapamayacağınız konusunda hemfikiriz.

Görebildiğim kadarıyla, Nisan ayının başında yukarıdaki kod, komisyoncunun GMT+4'te olduğunu söylemeye başlayacak. Demek istediğim, MT4'ün size söylediklerinden, geçen hafta komisyoncunun GMT+3'te olduğunu ve örneğin iBarShift() kullanımlarının, fiyatı hesaplamak istiyorsanız buna göre ayarlanması gerekebileceğini bilmenin hiçbir yolu yok. belirli GMT zamanlarında veya GMT zamanlarının sapmalarında aktivite.

BTW, yukarıdaki kodu bugün çalıştırdıysanız, komisyoncunuz neredeyse kesinlikle EEST'de olamaz. 30 Mart'a kadar EET'de olmalılar. Şu anda GMT+3'teyseler, EEST dışında bir şey kullanıyorlardır. (Bağlantı verdiğiniz sayfada "Yılın bu zamanında, EEST'deki konumlar artık EET'dedir" yazıyor).

 

gchrmt4 :

. . .

BTW, yukarıdaki kodu bugün çalıştırdıysanız, komisyoncunuz neredeyse kesinlikle EEST'de olamaz. 30 Mart'a kadar EET'de olmalılar. Şu anda GMT+3'teyseler, EEST dışında bir şey kullanıyorlardır. (Bağlantı verdiğiniz sayfada "Yılın bu zamanında, EEST'deki konumlar artık EET'dedir" yazıyor).

Aracım , MT4 sunucusundaki saat dilimini GMT+2'den GMT+3'e değiştirerek 17:00 New York kapanışına karşılık geliyor ve aynı zamanda ABD, 09 Mart 2014'te gerçekleşen Yaz Saati Uygulaması'nı değiştiriyor. Avrupa, GMT+2 standart saat için kabaca EET'ye karşılık gelir, dolayısıyla GMT+3 yaz saati uygulaması için EEST'ye karşılık gelir. Örneğin, bkz. Avrupa Saat Dilimleri . Gördüğünüz gibi, yerel saat dilimim EDT olduğunda ve aracımın saat dilimi EEST'ye karşılık geldiğinde kodu bugün çalıştırdığıma şüphe yok.

[1] Görebildiğim kadarıyla, Nisan ayının başında yukarıdaki kod, komisyoncunun GMT+4'te olduğunu söylemeye başlayacak.

[2] Demek istediğim, MT4'ün size söylediklerinden, önceki hafta, aracının GMT+3'te olduğunu ve örneğin iBarShift() kullanımlarının, isterseniz buna göre ayarlanması gerekebileceğini bilmenin bir yolu olmadığıdır. Belirli GMT zamanlarında veya GMT zamanlarının denkleştirmelerinde fiyat etkinliğini hesaplayın.

1. Nisan'da neden GMT+4'ü iade etsin? Yerel bilgisayarımın saati zaten yaz saati uygulamasına göre ayarlandı ve aracım zaten sunucusunu yaz saatini yansıtacak şekilde ayarladı, peki Nisan'da ne değişecek?

2. Bir komisyoncu, saatini gün ışığından yararlanma saatini yansıtacak şekilde değiştirebilir, bu da ofsetini GMT olarak değiştirir. Ancak bu değişikliği tahmin edebilirsiniz. Örneğin, yaz saatinin başladığı ve bittiği tarihler/saatler yıldan yıla değişse de, bu değişiklik tahmin edilebilir ve dolayısıyla programlanabilir. Sadece kuralı kodlayın. Ancak TimeGMT(), yerel saat dilimine, komisyoncu saat dilimine veya gün ışığından yararlanma saatine bakılmaksızın GMT'yi döndürmelidir.

Neredeyse kesin olarak bildiğiniz gibi... sorunlardan biri, komisyoncu saati ile GMT arasındaki farkın (a) yaz saati uygulamasına göre değişip değişmeyeceği ve (b) değişken olup olmadığı esasına göre belirlenemeyeceğidir. MT4'ün sağladığı bilgiler. Bu işlevlere ayrıntılı olarak bakmadım, ancak yalnızca MT4'ün sağladığı bilgilere dayanarak böyle bir hesaplama yapamayacağınız konusunda hemfikiriz.

Bir komisyoncu gün ışığından yararlanma saatini ayarlarsa, bu ayarlama ofsetini GMT olarak değiştirir, ancak yukarıda belirttiğim gibi, bu değişiklikleri tahmin edebilir ve onlar için ayarlayabilirsiniz. Veya bir yer (örneğin, Londra) gün ışığından yararlanma saatini ayarlarsa, yerel kuralı kodlayabilir ve böylece bu değişikliği tahmin edip ona göre ayarlayabilirsiniz.

 
Thirteen :

Bir komisyoncu gün ışığından yararlanma saatini ayarlarsa, bu ayarlama ofsetini GMT olarak değiştirir, ancak yukarıda belirttiğim gibi, bu değişiklikleri tahmin edebilir ve onlar için ayarlayabilirsiniz. Veya bir yer (örneğin, Londra) gün ışığından yararlanma saatini ayarlarsa, yerel kuralı kodlayabilir ve böylece bu değişikliği tahmin edip ona göre ayarlayabilirsiniz.

Değişikliklerin öngörülebilir ve kodlanabilir olduğu konusunda sizinle temelde aynı fikirdeyim ama yalnızca MT4'ün sağladığı bilgileri kullanmıyor. MT4'e "Londra'da x için eşdeğer zamanı ver" demek yerine, Londra GMT için "yerel kuralı kodlamanız" gerekir.

GMT+3 sunucu saatiniz, EEST'nin GMT+3 olması anlamında EEST'ye 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.

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. Bu, EET/EEST ile aynı 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.)

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. .

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.

 

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 ;)

Şaka yapıyorum, bunu kodlamaya çalışmamın hiçbir yolu yok. WHR bunu yapabilirdi, bahse girerim zaten yapmıştır.