Forumu kirletmemek için herhangi bir acemi sorusu. Profesyonel, kaçırmayın. Sensiz, hiçbir yerde - 6. - sayfa 557
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
İlkelere itiraz yok, ancak bir kişi bir testçide danışman çalıştırmak istiyor, bu nedenle seçenekleriniz ona uymuyor.
belck Benim versiyonumu kullan, hem gerçek hayatta hem de test cihazında çalışacak, ancak henüz kış-yaz saatine geçişi otomatik olarak hesaba katacak bir işlev yapmamış, bu yıl için geçiş süresini belirle gibi
Mart 2013'ten Kasım 2014'e kadar çalışacak ve doğru şekilde test edilecektir. Vardiyayı komisyoncunuza göre ayarlayınTest cihazında zamanın üretildiğinin nerede yazıldığını aramayacağım, bunu kendiniz biliyorsunuz. İşte kılavuzda ne yazıyor:
Oysa StringToTime() hakkında böyle bir ayrıntı yoktur.
Dikkate alınması gereken tek şey, test cihazının (DC sunucusu) zamanıdır. Ve buna göre, test ederken, bu baykuşun üzerinde çalışacağı aynı türden bir hesap geçmişine sahip olmalısınız.
Test cihazında zamanın üretildiğinin nerede yazıldığını aramayacağım, bunu kendiniz biliyorsunuz. İşte kılavuzda ne yazıyor:
Oysa StringToTime() hakkında böyle bir ayrıntı yoktur.
Dikkate alınması gereken tek şey, test cihazının (DC sunucusu) zamanıdır. Ve buna göre, test ederken, bu baykuşun üzerinde çalışacağı aynı türden bir hesap geçmişine sahip olmalısınız.
Alexey, evet, StrToTime() fonksiyonunun çalışmasına bir itirazım yok.Soru farklı. Doğru zamanı döndürür, ancak bugün 21:00, 9 Mart'tan önce 22:00. Bu nedenle, aracının DST'sini doğru bir şekilde hesaba katan uzun yazılı işlevlerim var.
Bu olmadan, Uzman Danışman belirli bir zaman çizelgesine göre çalışırsa, test etmek imkansızdır. Hala bir saat ileri gidiyor. Gerçek hayatta sorun yoktur, ancak test cihazı ile vardır. Geliştiricilerden uzun süredir zaman kayması hesaplama işlevini etkinleştirmelerini istiyorum. TimeGMT() yaptılar, ancak bilgisayarın yerel saatine ve saat dilimine bağlı. Ve bir komisyoncu vardiyasına sahip olmanız gerekiyor. Ve onların DST'si bizimkinden farklı. Komisyoncular Kasım ayının ilk Pazar gününü Mart ayının ikinci Pazar gününe ve Rusya (varsa..) Ekim ayının son Pazar günü Mart ayının son Pazar gününe taşır. Yani fonksiyonları yazmak gerekirken.
İlkelere itiraz yok, ancak bir kişi bir testçide danışman çalıştırmak istiyor, bu nedenle seçenekleriniz ona uymuyor.
belck Benim versiyonumu kullan, hem gerçek hayatta hem de test cihazında çalışacak, ancak henüz kış-yaz saatine geçişi otomatik olarak hesaba katacak bir işlev yapmamış, bu yıl için geçiş süresini belirle gibi
Mart 2013'ten Kasım 2014'e kadar çalışacak ve doğru şekilde test edilecektir. Vardiyayı komisyoncunuza göre ayarlayınkuyu. teşekkür etmek. sonucu size bildireceğim.
< h4 çizelgelerinde 8 Mart'tan önceki Cuma ve Cuma gününün son çubuğunun zamanını kontrol etmek gerekir. Bu zamanlar çakışırsa, hrd değeri sabittir ve kış - yaz saatine geçişe bağlı değildir ve daha sonra kış-yaz geçişlerinden bağımsız olarak test sırasında da dahil olmak üzere her şey oldukça basittir ve doğru şekilde çalışacaktır.
ve eğer bu iki zaman farklıysa (1 saat fark ediyorsa) o zaman daha önce yazdığım gibi.
M1 grafiğinde mevcut Cuma ve Cuma gününün 8 Mart'tan önceki son çubuğunun zamanını karşılaştırmak gerekir. Bu zamanlar çakışırsa, hrd değeri sabittir ve kış - yaz saatine geçişe bağlı değildir ve daha sonra kış-yaz geçişlerinden bağımsız olarak test sırasında da dahil olmak üzere her şey oldukça basittir ve doğru şekilde çalışacaktır.
ve eğer bu iki zaman farklıysa (1 saat fark ediyorsa) o zaman daha önce yazdığım gibi.
Ve komisyoncu neden kodda 15 dakikalık süre yazıyor, yani seans bitmeden 15 dakika önce portföyler kaydırılıyor mu diyorsunuz?Tabii ki bazı döviz çiftlerinde böyle anlar ve iyi seviyeler fark ettim.
örneğin, seansın bitiminden 1 dakika önce olsa bile, anlaşmaları kapatmak istiyorum, çünkü hafta sonu için bir emir olduğunda, Pazartesi günü açılış fiyatı 100 veya 200, hatta yanlara sıçrayabilir. daha fazla puan. ve bu ani hareket her zaman benim avantajıma olmayabilir.
henüz test edilmedi. Bugün daha sonra test ediyorum.
Eh, bu test cihazında ve çalışmamalı.
Fonksiyonlar o anki zamana göre verilir ancak TimeCurrent() ve TimeDayOfWeek() doğru çalıştığı için yukarıda yazdıklarım işe yarayacaktır. Sadece brokerlerin yaz ve kış saatlerine geçiş fonksiyonunu eklemek gerekir, yani. hr parametresi. Geçiş genellikle ABD DST saatidir (Kasım ayının ilk Pazar günü, Mart ayının ikinci Pazar günü), ancak bazı brokerler transfer yapmaz, bu nedenle
Sunucu zamanı, komisyoncu zamanı mı? komisyoncu Rusya'da bulunuyorsa ve ben Ukrayna'daysam, o zaman yaz veya kış saatine geçişleri yok mu? o zaman sunucu saatine göre bir geçişim yok, yerel saate göre akım? Kafam karıştı.
Broker fiyatlarının zamanını ve yerel olanı karşılaştırmanıza gerek yoktur. Saatinizi ne kadar hareket ettirirseniz ettirin, grafikteki broker oturumunun bitiş saati değişmeyecektir. 8-9 Mart'ta broker kotasyonlarının yaz saatine geçişi ile ilgiliydi ve bazı brokerler bunu yapıyor, bazıları yapmıyor.
Yazdım - 9 Mart'tan önceki ve sonraki son çubukların zamanına ilişkin tablolara bakın, eğer aynılarsa, son basit seçeneği kullanın, eğer bir saate göre farklılık gösterirlerse, o zaman daha karmaşık.
Beyler şapka çıkartın :) Hem formüller hem de DayOfWeek() TimeDayOfWeek(datetimedate) ve benzer formüller test cihazında doğru şekilde çalışacaktır. Test cihazı, işlediği onay süresini simüle eder, bu nedenle sunucunun bilinen son zamanını alan DayOfWeek() de çalışır. Elbette TimeDayOfWeek (dt1) kullanmak daha doğrudur.
Genel olarak, her şey doğrudur, sadece komisyoncunun kışa geçiş zamanını dikkate almaya devam eder - eğer varsa, yukarıda yazdığım gibi yaz saati.