Londoner Ausbruch

 

Liebe Forumsmitglieder,

Seit ein paar Wochen versuche ich mit MQL4 weiterzukommen, aber was für eine Herausforderung!!! Ich hatte gehofft, dass ich bereits ein Experte bin, aber das bin ich nicht und ich hoffe, dass ich ein wenig Hilfe bekomme.

Ich versuche, einen Breakout Expert Advisor für die Eröffnungssitzung in London zu erstellen. Ich möchte, dass mein Expert Advisor das Hoch und Tief der 5 Bars vor der Londoner Eröffnung berechnet und dann das Hoch und Tief berechnet.

Für diese Funktion nehme ich an, dass ich das Hoch der Funktion iHigh und das Tief der Funktion iLow verwenden muss, um den Bereich zu berechnen. Aber diese Spanne wird sich im Laufe des Tages ändern. Ich möchte, dass die Höchst- und Tiefstwerte dieses Bereichs statisch und nicht variabel sind.

Hat jemand eine Idee?

Vielen Dank im Voraus!

 
Nour:

Liebe Forumsmitglieder,

Seit ein paar Wochen versuche ich mit MQL4 weiterzukommen, aber was für eine Herausforderung!!! Ich hatte gehofft, dass ich bereits ein Experte bin, aber das bin ich nicht und ich hoffe, dass ich ein wenig Hilfe bekomme.

Ich versuche, einen Breakout Expert Advisor für die Eröffnungssitzung in London zu erstellen. Ich möchte, dass mein Expert Advisor das Hoch und Tief der 5 Bars vor der Londoner Eröffnung berechnet und dann das Hoch und Tief berechnet.

Für diese Funktion nehme ich an, dass ich das Hoch der Funktion iHigh und das Tief der Funktion iLow verwenden muss, um den Bereich zu berechnen. Aber diese Spanne wird sich im Laufe des Tages ändern. Ich möchte, dass die Höchst- und Tiefstwerte dieses Bereichs statisch und nicht variabel sind.

Hat jemand eine Idee?

Vielen Dank im Voraus!


Wie findet man die Bar, in der die Londoner Eröffnung beginnt...

Zeigen Sie, wie Sie es machen

 

Das ist ein weiteres Problem deVries, ich weiß nicht, wie die Bar zu finden, wo London öffnet...

Ich bin noch ziemlich neu in MQL4

 

... übersehe ich etwas, oder sind die in MQL4 eingebauten Datums-/Zeitfunktionen für diese Art von Dingen immer noch unzureichend?

Zwei Probleme:

* Sie können den Offset zwischen dem Broker-Server und GMT nicht zuverlässig ermitteln, weil er sich (a) mit der Sommerzeit ändern kann und (b) jeder Vergleich von TimeCurrent() mit TimeGMT() zur Berechnung eines Offsets an Wochenenden fehlschlägt.

* Obwohl Sie die aktuelle Zeitverschiebung abrufen können, während der Markt geöffnet ist, gibt es keine eingebaute Möglichkeit, die GMT-Zeit in eine andere Zeitzone wie London zu übersetzen.

Mit anderen Worten: Es gibt keine eingebaute Möglichkeit, festzustellen, dass (a) der Server des Brokers auf CET läuft und daher (b) die Londoner Zeiten für jeden Bar 1 Stunde hinter der von MT4 gemeldeten Zeit liegen.

 

Nour:

Das ist ein weiteres Problem deVries, ich weiß nicht, wie die Bar zu finden, wo London öffnet...

Ich bin noch ziemlich neu in MQL4

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

... übersehe ich etwas, oder sind die in MQL4 eingebauten Datums-/Zeitfunktionen für diese Art von Dingen immer noch unzureichend?

Zwei Probleme:

* Sie können den Offset zwischen dem Broker-Server und GMT nicht zuverlässig ermitteln, weil er sich (a) mit der Sommerzeit ändern kann und (b) jeder Vergleich von TimeCurrent() mit TimeGMT() zur Berechnung eines Offsets an Wochenenden fehlschlägt.

* Obwohl Sie die aktuelle Zeitverschiebung abrufen können, während der Markt geöffnet ist, gibt es keine eingebaute Möglichkeit, die GMT-Zeit in eine andere Zeitzone wie London zu übersetzen.

Mit anderen Worten: Es gibt keine eingebaute Möglichkeit, festzustellen, dass (a) der Server des Brokers auf CET läuft und daher (b) die Londoner Zeiten für jeden Balken 1 Stunde hinter der von MT4 gemeldeten Zeit liegen.


Es scheint, dass TimeGMT() sich nicht mit der Sommerzeit ändert. Ich lebe zum Beispiel in den USA, also ist meine lokale Zeitzone derzeit EDT. Der MT4-Server meines Brokers ist derzeit EEST. Betrachten Sie nun den folgenden Code und seine Ausgabe:

   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 Experte TestEA-1 EURUSD,H1: erfolgreich geladen

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

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

17:52:28 TestEA-1 EURUSD,H1: 3. Sommerzeitanpassung: -1

17:52:28 TestEA-1 EURUSD,H1: 4. GMTOffset für TimeLocal = 4

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

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

Ich habe die obige GMT-Zeit mit der von London verglichen, und sie waren identisch (London stellt erst Ende März auf BST um). Ich glaube also, dass TimeGMT() GMT zurückgibt, ohne die lokale Sommerzeitanpassung hinzuzufügen. EDT ist definiert als UTC-4 und EEST ist definiert als UTC+3.

Wenn Sie außerdem feststellen wollen, wann die Sommerzeit in den USA oder in der EU beginnt und endet, finden Sie hier die entsprechenden Funktionen.

 
Thirteen:

Ich habe die GMT-Zeit oben mit der von London verglichen [...]

Wie Sie sicherlich wissen, besteht eines der Probleme darin, dass die Abweichung zwischen der Zeit des Brokers und der GMT (a) aufgrund der Sommerzeit variabel sein kann oder nicht und (b) ob sie variabel ist oder nicht, kann anhand der von MT4 bereitgestellten Informationen nicht bestimmt werden. Ich habe mir diese Funktionen nicht im Detail angesehen, aber ich denke, wir sind uns einig, dass Sie eine solche Berechnung nicht allein auf der Grundlage der von MT4 bereitgestellten Informationen durchführen können.

Soweit ich sehen kann, wird der obige Code ab Anfang April sagen, dass der Broker auf GMT+4 steht. Ich will damit sagen, dass es keine Möglichkeit gibt, aus den Informationen von MT4 zu schließen, dass der Broker in der vorangegangenen Woche GMT+3 hatte, und dass die Verwendung von z. B. iBarShift() entsprechend angepasst werden muss, wenn Sie die Kursaktivität zu bestimmten GMT-Zeiten oder Offsets von GMT-Zeiten ermitteln wollen.

Übrigens, wenn Sie den obigen Code heute ausgeführt haben, kann Ihr Broker mit ziemlicher Sicherheit nicht auf EEST stehen. Er sollte bis zum 30. März auf EET stehen. Wenn sie derzeit auf GMT+3 sind, dann verwenden sie etwas anderes als EEST. (Auf der Seite, die Sie verlinkt haben, heißt es: "Während dieser Jahreszeit sind die Orte, die auf EEST stehen, jetzt auf EET").

 

gchrmt4:

. . .

Übrigens, wenn Sie den obigen Code heute ausgeführt haben, kann Ihr Broker mit ziemlicher Sicherheit nicht auf EEST sein. Er sollte bis zum 30. März auf EET stehen. Wenn sie derzeit auf GMT+3 sind, verwenden sie etwas anderes als EEST. (Auf der Seite, die Sie verlinkt haben, heißt es: "Während dieser Jahreszeit sind Standorte, die auf EEST eingestellt sind, jetzt auf EET eingestellt").

Mein Broker ändert die Zeitzone auf seinem MT4-Server von GMT+2 auf GMT+3, um dem New Yorker Börsenschluss um 17 Uhr zu entsprechen, und zwar zur gleichen Zeit, in der die USA auf Sommerzeit umstellen, was am 09. März 2014 geschah. In Europa entspricht GMT+2 ungefähr EET für die Standardzeit und GMT+3 entspricht EEST für die Sommerzeit. Siehe z. B. Europäische Zeitzonen. Wie Sie also sehen können, habe ich den Code heute zweifellos ausgeführt, als meine lokale Zeitzone EDT war und die Zeitzone meines Brokers EEST entsprach.

[1] Soweit ich sehen kann, wird der obige Code ab Anfang April sagen, dass der Broker auf GMT+4 steht.

[2] Ich will damit sagen, dass man nicht wissen kann, was MT4 einem mitteilt, dass der Broker in der Vorwoche GMT+3 hatte, und dass die Verwendung von z. B. iBarShift() entsprechend angepasst werden muss, wenn man die Preisaktivität zu bestimmten GMT-Zeiten oder Offsets von GMT-Zeiten ermitteln möchte.

1. Warum sollte es im April GMT+4 zurückgeben? Die Zeit meines lokalen Computers ist bereits an die Sommerzeit angepasst, und mein Broker hat seinen Server bereits an die Sommerzeit angepasst, was wird sich also im April ändern?

2. Ein Broker kann seine Zeit auf die Sommerzeit umstellen, wodurch sich sein Offset zur GMT ändern würde. Aber Sie können diese Änderung vorhersagen. Die Daten/Uhrzeiten, an denen die Sommerzeit beginnt und endet, ändern sich zwar von Jahr zu Jahr, aber diese Änderung ist vorhersehbar - und daher programmierbar. Programmieren Sie einfach die Regel. Aber TimeGMT() sollte GMT zurückgeben, unabhängig von der lokalen Zeitzone, der Maklerzeitzone oder der Sommerzeitverschiebung.

Wie Sie sicherlich wissen, besteht eines der Probleme darin, dass die Abweichung zwischen der Zeit des Brokers und der GMT (a) je nach Sommerzeit variabel sein kann oder nicht und (b) ob sie variabel ist oder nicht, kann anhand der Informationen, die MT4 liefert, nicht bestimmt werden. Ich habe mir diese Funktionen nicht im Detail angesehen, aber ich denke, wir sind uns einig, dass Sie eine solche Berechnung nicht allein auf der Grundlage der von MT4 bereitgestellten Informationen durchführen können.

Wenn ein Broker sich an die Sommerzeit anpasst, dann würde diese Anpassung seinen Offset zur GMT verändern, aber wie ich oben schon sagte, können Sie diese Änderungen vorhersagen und sich an sie anpassen. Oder wenn ein Ort (z. B. London) die Sommerzeit anpasst, können Sie die lokale Regel kodieren und so diese Änderung vorhersagen und anpassen.

 
Thirteen:

Wenn sich ein Makler an die Sommerzeit anpasst, dann würde sich durch diese Anpassung sein Offset zur GMT ändern, aber wie ich oben schon sagte, können Sie diese Änderungen vorhersagen und sich darauf einstellen. Oder wenn ein Ort (z. B. London) die Sommerzeit anpasst, können Sie die örtliche Regel kodieren und so diese Änderung vorhersagen und sich darauf einstellen.

Grundsätzlich stimme ich Ihnen zu, dass die Änderungen vorhersehbar und kodierbar sind... aber nicht nur mit Informationen, die MT4 selbst liefert. Sie müssen die "lokale Regel" für London GMT kodieren, anstatt MT4 zu sagen: "Gib mir die entsprechende Zeit für x in London".

Ihre Serverzeit von GMT+3 mag EEST in dem Sinne entsprechen, dass EEST GMT+3 ist, aber sowohl Wikipedia als auch worldclock.com zufolge sollte noch nirgendwo EEST herrschen. Die Umstellung sollte nicht vor dem 30. März erfolgen. Die aktuelle Zeit in Zypern, Griechenland, Israel usw. ist GMT+2.

Daher ist es wahrscheinlich, dass ein Broker seine Server auf GMT+2 laufen lässt, aber die Umstellung auf Sommerzeit an den US-Daten und nicht an den europäischen Daten vornimmt. Das ist nicht dasselbe wie EET/EEST. (Und es ist sogar noch weniger vorhersehbar, wenn es darum geht, einen Code zu schreiben, der Zeiten und Daten automatisch anpasst, ohne den Benutzer nach irgendwelchen Eingaben darüber zu fragen, welche Zeiteinstellungen der Broker verwendet.)

Wenn also der Broker vor kurzem von GMT+2 auf GMT+3 umgestellt hat und nicht von GMT+3 auf GMT+4, bedeutet dies, dass der aktuelle Offset zwischen Brokerzeit und GMT falsch wäre, wenn man ihn auf die Balken der letzten Woche, also vor der Zeitumstellung in den USA, anwenden wollte. In dieser Woche sind die Bars des Brokers 3 Stunden vor London. Letzte Woche waren sie 2 Stunden voraus. (Und ab dem 30. März werden sie wieder 2 Stunden voraus sein.) Wenn Sie diesen aktuellen Versatz von 3 Stunden nehmen und damit versuchen, den Kurs um 8 Uhr morgens Londoner Zeit an einem Tag der letzten Woche zu ermitteln, erhalten Sie die falsche Antwort.

Ich will damit nur sagen, dass die Informationen, die man nur von MT4 selbst erhalten kann - der aktuelle Offset zwischen Brokerzeit und GMT - in der Praxis unzureichend sind, um z. B. den Eröffnungskurs in London am vergangenen Mittwoch zu ermitteln.

 

Wie könnte MT4 für diese Aufgabe besser geeignet gemacht werden? Ich weiß nicht, wie es Ihnen geht, aber ich hätte sicher keine Freude an der Aufgabe, einen regionalen historischen GMT-Offset-Rechner zu erstellen. Können Sie sich das nur vorstellen? omg. Wenn ich das jemals schaffe, werde ich es auf den Markt bringen, und Sie sollten besser ein dickes Scheckbuch haben ;)

Ich mache nur Spaß, ich werde auf keinen Fall versuchen, das zu programmieren. WHR könnte es aber tun, ich wette, er hat es bereits getan.

Grund der Beschwerde: