Umgang mit Zeit (Teil 1): Die Grundlagen
1 479
0
Welche Zeit
Genaues Timing kann ein entscheidendes Element beim Handel sein. Ist die Börse in London oder New York zur aktuellen Stunde bereits geöffnet oder noch nicht, wann beginnt und endet die Handelszeit für den Forex-Handel? Für einen Händler, der manuell und live handelt, ist dies kein großes Problem. Mit Hilfe verschiedener Internet-Tools, der Spezifikationen der Finanzinstrumente und der eigenen Zeit kann man schnell erkennen, wann der richtige Zeitpunkt für die eigene Strategie ist. Für manche Händler, die nur auf die Entwicklung der Kurse achten, kaufen und verkaufen, wenn die Kursentwicklung ihnen ein Signal gibt, ist der Zeitpunkt eher unwichtig. Anders verhält es sich bei den Händlern, die "Night Scalping" betreiben, die nach Börsenschluss in New York und vor Öffnung der (Aktien-)Märkte in der EU handeln, oder bei jenen, die gezielt handeln, z.B. beim "London Breakout", oder sonst in der umsatzstärksten Zeit, oder bei all jenen, die mit Aktien oder Futures handeln. Diese Händler können sich nicht nach den Zeiten des Brokers richten, sondern müssen die tatsächlichen Ortszeiten in den USA, Japan, London, der EU oder Moskau verwenden, zu denen die jeweilige Börse öffnet oder schließt, oder die speziellen Zeiten, zu denen ein spezieller Future gehandelt wird.
Sommerzeit, Winterzeit und Broker-Offset
Wie gesagt, Händler, die zum Kaufen und Verkaufen vor dem Bildschirm sitzen, können mit den unterschiedlichen Zeiten gut umgehen. Sei es über das Internet oder bestimmte Funktionen, Werte oder Uhren, die der PC bereithält und die mit MQL-Funktionen wie TimeGMT(), TimeGMTOffset() und anderen jederzeit abgerufen werden können. Anders sieht es aus, wenn man ein Handelsprogramm mit historischen Daten schreiben und testen will, das zeitbezogen handelt. Eigentlich sollte die Frage, analog zum Live-Handel, genauso einfach zu beantworten sein.
Ausgehend von UTC (Universal Coordinated Time) oder Greenich Mean Time (GMT, https://greenwichmeantime.com/what-is-gmt/) müsste man lediglich die geografische oder instrumentenbedingte Zeitverschiebung hinzufügen und man wüsste, wie spät es wo ist. Doch so einfach ist es nicht. Es gibt die Umstellung von Winter- und Sommerzeit (DST oder Daylight Saving Time), bei der je nach Zeit eine Stunde hinzugefügt oder abgezogen wird. Allerdings nicht einheitlich, sondern jedes Land oder jede Region wie z. B. Europa hat seine eigene Definition, die manchmal seit Jahren konstant ist (EU und USA) oder von Zeit zu Zeit geändert wird wie in Russland, wo sie 2014 abgeschafft wurde. In der EU gab es 2018 eine Diskussion inklusive einer Umfrage zur Frage der Abschaffung der jährlichen Zeitumstellung (https://ec.europa.eu/germany/news/20180831-konsultation-sommerzeit_de), die eine Mehrheit für die Abschaffung ergab, sodass die Kommission einen Legislativvorschlag für die Abschaffung der Zeitumstellung (https://ec.europa.eu/germany/news/20180914-kommission-gesetzesvorschlag-ende-zeitumstellung_de) vorlegte, der dann wieder im Sande verlief.
Als ob das nicht schon chaotisch genug wäre, mischen jetzt auch noch Broker mit, die jeweils ihre eigene Serverzeit definieren. Im Jahr 2015 schrieb mir ein deutscher Broker:
- Bis zum 8. März 2015 ist unsere MT4-Serverzeit auf Londoner Zeit ( = GMT ) eingestellt.
- Ab dem 8. März 2015, bis zum 29. März, ist er auf CET ( GMT + 1 ) eingestellt.
- Ab dem 29. März ist der Server auf Londoner Zeit ( = GMT + 1 ) eingestellt.
Das heißt, der deutsche Broker verwendet GMT + DST-USA, oder (hauptsächlich) Londoner Zeit + DST der USA, darauf muss man erst einmal kommen, obwohl die Gründe verständlich sind, denn der Devisenhandel beginnt um 17:00 Uhr New Yorker Zeit, und die unterliegt der amerikanischen Zeitumstellung. Das hat zur Folge, dass für jemanden, der in Frankfurt sitzt, der Devisenhandel manchmal um 21:00 Uhr, normalerweise um 22:00 Uhr und für eine/zwei Wochen im Herbst um 23:00 Uhr beginnt.
Für uns als Händler und Kunden ist das eher wie in einem Kindergarten. Jeder macht, was und wie er will. Der Händler oder der Entwickler wird also mit vielen verschiedenen Zeiten konfrontiert, die alle wichtig sein könnten, und die alle aus den "Bordmitteln" von MQL ermittelt werden müssten - aber leider nicht, wenn ein Indikator, ein Skript oder ein EA im Strategietester läuft.
Das werden wir ändern. Ohne den Broker fragen zu müssen, werden wir seine jeweiligen Zeitverschiebungen ermitteln, sodass GMT ganz einfach zu jedem Zeitpunkt vor jedem Zeitstempel im Strategietester ermittelt werden kann und anschließend natürlich auch jede weitere benötigte Ortszeit wie beispielsweise die New Yorker Zeit. Außerdem, weil es sich gerade in diesem Zusammenhang ergab, auch die verbleibende Zeit, die der Devisenmarkt noch geöffnet ist, für alle Händler, die ihre offenen Positionen ggf. noch vor dem Wochenende schließen wollen. Zu diesen Funktionen werden wir aber erst im zweiten Artikel kommen, denn jetzt werden wir einige Makrosubstitutionen entwickeln, die uns für die genannten Funktionen die Berechnungen und Darstellungen zur Steuerung vereinfachen werden.
Makrosubstitutionen
Alles, was kommt, steht in der (beigefügten) Include-Datei HandelnmitZeitTeil1.mqh. Am Anfang dieser Datei befinden sich die verschiedenen Makro-Substitutionen.
Zunächst einmal gibt es einige Zeitverschiebungen von verschiedenen Regionen, damit man sie nicht immer wieder ableiten oder suchen muss:
//--- defines #define TokyoShift -32400 // always 9h #define NYShift 18000 // winter 17h=22h GMT: NYTime + NYshift = GMT #define LondonShift 0 // winter London offset #define SidneyShift -39600 // winter Sidney offset #define FfmShift -3600 // winter Frankfurt offset #define MoskwaShift -10800 // winter Moscow offset #define FxOPEN 61200 // = NY 17:00 = 17*3600 #define FxCLOSE 61200 // = NY 17:00 = 17*3600 #define WeekInSec 604800 // 60sec*60min*24h*7d = 604800 => 1 Week
Zum besseren Verständnis einigen wir uns darauf, dass GMT ein unveränderlicher Zeitanker ist, während die verschiedenen Ortszeiten, New York, London oder Moskau, sich jeweils durch eine andere (variable) Zeitverschiebung von ihr unterscheiden. Ebenso werden wir die Verschiebungen aufgrund der Sommer- oder Winterzeit als variabel bezeichnen. Der Grund dafür ist einfach. Die Vorzeichen der variablen Zeitdifferenzen sind so definiert, dass gilt:
Variable Zeit + variable Zeitverschiebung = GMT
Einige Beispiele:
Moskau (16h) + Moskau Offset (-3h) = GMT (13h)
New York Zeit (16h) + New York Offset (+5h) = GMT (21h)
New York Zeit (16h) + (New York Offset (+5h) + DST_US(-1h)) = GMT (20h)
Frankfurt Zeit (16h) + (Frankfurt Offset (-1h) + DST_US(-1h)) = GMT (14h)
Klammern beachten! Sie werden wichtig, wenn die sich ändernden Zeiten aus GMT berechnet werden sollen:
New York Zeit (16h) = GMT (20h) - (New York Offset (+5h) + DST_US(-1h)) => 20 -(+5 + -1) = 20 - 5 +1 = 16h
Frankfurt Zeit (16h) = GMT (14h) - (Frankfurt Offset (-1h) + DST_US(-1h)) => 14 -( -1 + -1) = 14 +1 +1 = 16h
Glauben Sie mir, es ist ein ewiger Quell für Vorzeichenfehler und Missverständnisse.
In dieser Form behandeln auch MQL5 und der PC die Zeitunterschiede wie TimeGMTOffset(): TimeLocal() + TimeGMTOffset() = TimeGMT()) oder TimeDaylightSavings(): TimeLocal() + TimeDaylightSavings() = Winter- oder Standard-Ortszeit des PCs.
Als letztes dieses Teils gibt es FxOpen und FxClose und die Zeitdauer einer ganzen Woche in Sekunden WeekInSec, weil diese Bezeichnungen leichter zu verstehen sind, als wenn im Code plötzlich z.B. 604800 zu einer Variablen hinzugefügt wird.
Dann kommen zwei einfache Vereinfachungen der Variablenausgabe. TOSTR(A) gibt den Namen der Variablen und ihren Wert aus - ganz brauchbar. Dann das Array mit den Abkürzungen der Wochentage. Es wird in dem für dieses Projekt entwickelten Code mehrfach verwendet und hilft, Platz in der Zeile zu sparen, aber auch bei der Orientierung der berechneten Zeitstempel:
#define TOSTR(A) #A+":"+(string)(A)+" " // Print (TOSTR(hGMT)); => hGMT:22 (s.b.) string _WkDy[] = // week days { "Su.", "Mo.", "Tu.", "We.", "Th.", "Fr.", "Sa.", "Su." };
Es folgen nun Alternativen zur Zeitberechnung, die den Umweg vermeiden, der MQ-Struktur MqlDateTime eine Zeit zuzuweisen, um einen Einzelwert auszulesen. Sie werden direkt berechnet:
#define DoWi(t) ((int)(((t-259200)%604800)/86400)) // (int)Day of Week Su=0, Mo=1,... #define DoWs(t) (_WkDy[DoWi(t)]) // Day of Week as: Su., Mo., Tu., ....
DoWi(t) (Wochentag als Ganzzahl) ermittelt den Wochentag als Ganzzahl (Sonntag:0, Montag:1, ...), während DoWs(t) Wochentag als Zeichenkette) mit DoWi(t) und dem Array _WkDy[] den abgekürzten Wochentag als Text liefert. Da sich der zweite Teil des Artikels mit den letzten und ersten Stunden des Wochenendes befasst, werden diese Makrosubstitutionen häufiger verwendet werden.
#define SoD(t) ((int)((t)%86400)) // Seconds of Day #define SoW(t) ((int)((t-259200)%604800)) // Seconds of Week
SoD(t) (Seconds of the day) gibt die Anzahl der Sekunden seit 00:00 der vergangenen Zeit zurück. So berechnet SoD(TimeCurrent()) auf diese einfache Weise die Dauer in Sekunden, die eine Tageskerze bereits existiert. Analog dazu berechnet SoW(t) die Anzahl der Sekunden seit dem letzten Sonntag 00:00. Auf diese Weise kann man leicht den Prozentsatz der verstrichenen Zeit (in Sekunden) und die verbleibende Zeit dieser Tageskerze berechnen. Wenn Sie diesen Wert durch 864 (=0,01*24*60*60) teilen, erhalten Sie den Prozentsatz, den der Tag bereits vergangen ist:
(double)SoD(D’20210817 15:34‘) / 864. = 64.86% 86400 - SoD(D’20210817 15:34‘) = Print("D'20210817 15:34': ", DoubleToString((double)SoD(D'20210817 15:34')/864.0, 2),"% ", 86400 - SoD(D’20210817 15:34‘),“ sec left“ );
Diese Berechnungen funktionieren entsprechend (wer immer es braucht):
#define MoH(t) (int(((t)%3600)/60)) // Minute of Hour #define MoD(t) ((int)(((t)%86400)/60)) // Minute of Day 00:00=(int)0 .. 23:59=1439
Die Funktion ToD(t) gibt die Sekunden des Tages als Datentyp "datetime" zurück. Dies verhindert die Warnmeldungen des Compilers in der einen oder anderen Situation:
#define ToD(t) ((t)%86400) // Time of Day in Sec (datetime) 86400=24*60*60
Die Funktion HoW(t) liefert die Anzahl der Stunden, die seit Sonntag 00:00 Uhr vergangen sind:
#define HoW(t) (DoW(t)*24+HoD(t)) // Hour of Week 0..7*24 = 0..168 0..5*24 = 0..120
Damit kann die Stunde des Tages auf einfache Weise berechnet werden, das Ergebnis ist eine Ganzzahl, kein Datum:
#define HoD(t) ((int)(((t)%86400)/3600)) //Hour of Day: 2018.02.03 17:55 => 17
Das Gleiche, nur "kommerziell" gerundet:
#define rndHoD(t) ((int)((((t)%86400)+1800)/3600))%24 // rounded Hour of Day 17:55 => 18
und nochmal das Gleiche als Typ datetime:
#define rndHoT(t) ((t+1800)-((t+1800)%3600)) // rounded Hour of Time: 2018.02.03 17:55:56 => (datetime) 2018.02.03 18:00:00
Der Zeitpunkt des Tagesbeginns als datetime, der sonst extra beim Aufruf des Tageszeitrahmens D1 ermittelt werden müsste:
#define BoD(t) ((t)-((t)%86400)) // Begin of day 17.5. 12:54 => 17.5. 00:00:00
Der Zeitpunkt des Wochenbeginns als datetime, der sonst durch Aufruf des wöchentlichen Zeitrahmens ermittelt werden müsste:
#define BoW(t) ((t)-((t-172800)%604800 - 86400)) // Begin of Week, Su, 00:00
Die folgenden Code-Teile verwenden die MQL-Strukturen und -Funktionen, weil mir die Konvertierung zu kompliziert war, z.B. wegen der Schaltjahre, aber sie folgen dem gleichen Formatprinzip von oben, den Zeitfunktionen mit Namen aus meist drei Buchstaben oder Akronymen, DoY, (=Day of Year), MoY (Month of Year), und YoY (Year of Year):
MqlDateTime tΤ; // hidden auxiliary variable: the Τ is a Greek characker, so virtually no danger int DoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.day_of_year); } int MoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.mon); } int YoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.year); }
Hier ist noch die Berechnung der Woche des Jahres nach US-Definition:
int WoY(datetime t) //Su=newWeek Week of Year = nWeek(t)-nWeeks(1.1.) CalOneWeek:604800, Su.22:00-Su.22:00 = 7*24*60*60 = 604800 { return(int((t-259200) / 604800) - int((t-172800 - DoY(t)*86400) / 604800) + 1); // calculation acc. to USA }
(Mehr über die wöchentlichen Berechnungen hier: https://en.wikipedia.org/wiki/Week#Numbering)
Die saisonalen und lokalen Zeitverschiebungen
Nachdem wir die Vereinfachungen, die die Funktionen benötigen, deklariert und erklärt haben, bereiten wir nun das weite Feld der verschiedenen lokalen und saisonalen Zeitverschiebungen vor und wie die Broker und MQL5 mit ihnen umgehen. Beginnen wir mit unserer Programmiersprache MQL5.
Die Zeit in MQL5
Die erste und unmittelbare Zeit ist diejenige, mit der der Broker seine Kurse bereitstellt, die sich in der Eröffnungszeit der Balken widerspiegelt und die mit TimeCurrent() nach dem letzten erhaltenen Kurs abgefragt werden kann. In vielen Fällen — und das mag überraschen — ist diese Zeit relativ unwichtig und dient nur dazu, die Balken, Kurse aber auch Handelsaktivitäten zeitlich zu sortieren. Sie hat also nur in der Umgebung des Terminals ihre Relevanz und das sowohl im Live-Handel als auch im Strategietester.
Dann gibt es noch TimeTradeServer(): "Gibt laufende Berechnungszeit des Handelsservers zurück. Zum Unterschied von der Funktion TimeCurrent(), wird die Zeitberechnung im Client-Terminal durchgeführt und hängt von Zeitenstellungen im Benutzercomputer ab." ABER: "Im Strategietester ist TimeTradeServer() immer gleich der TimeCurrent() Serverzeit." Diese Funktion ist also keine große Hilfe für ein Programm, das für den Live-Betrieb im Strategietester optimiert werden soll.
Gleiches gilt für TimeGMT() und TimeLocal(): "Im Strategietester ist die TimeGMT() Zeit immer gleich der modellierten Serverzeit TimeTradeServer().", und diese ist gleich TimeCurrent().
Das macht auch TimeGMTOffset() im Strategietester "nutzlos", denn TimeGMTOffset() = TimeGMT() - TimeLocal(), und das ist dann immer und zu jeder Zeit Null. :(
Als letztes bleibt noch TimeDaylightSavings(): "Gibt Korrektur für Sommerzeit in Sekunden zurück, wenn der übergang zur Sommerzeit stattfand. Hängt von den Einstellungen auf dem Benutzerrechner ab. ... Wenn der übergang zur Winterzeit (Standardzeit) stattfand, gibt 0 zurück."
Hier ist der Ausdruck von einem Live-Demokonto (MQ ist, wie man am Datum erkennen kann, zum Zeitpunkt der Abfrage in der EU und den USA in der Sommerzeit):
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeCurrent: 10:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeTradeServer: 10:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeLocal: 09:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeGMT: 07:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeDaylightSavings: -3600 h: -1
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeGMTOffset: -7200 h: -2
und hier der Ausdruck desselben Kontos im Strategie-Tester (Debugging):
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeCurrent: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeTradeServer: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeLocal: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeGMT: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeDaylightSavings: 0 h: 0
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeGMTOffset: 0 h: 0
All diese Funktionen helfen nicht im Strategietester, sondern nur in der Live-Situation. So haben wir nur TimeCurrent(), um alle anderen Zeiten selbst zu berechnen und das bei dem Chaos. Naja, leicht kann jeder ;)
Theoretisch könnte man meinen, dass man alles vom Broker erfahren kann, wie er die Zeitverschiebungen für die Zeitstempel der Kurse definiert. Hier ist zum Beispiel die Antwort von Alpari:
(GMT+2/GMT +3 DST) beginnen und am Freitag um 23:55:00 Server Time enden. Im Sommer
beginnt der Handel sonntags um 21:05 Uhr GMT, während der Winterzeit ist es
22:05 GMT an einem Sonntag.
Es stellt sich heraus, dass dies nur teilweise richtig ist. Erstens wird die Übergangszeit, in der sich EU und USA nicht gleichermaßen in Sommer- oder Winterzeit befinden, nicht erwähnt und zweitens enden die Preisübertragungen in dieser Übergangszeit, z.B. am 26.3.2021, nicht um 23:55, sondern um 22:55. davor und danach wieder um 23:55.
Doch bevor wir weitermachen, noch ein kleiner Überblick über die verschiedenen Zeitzonen und ihre Abkürzungen. Am hilfreichsten zu diesem ganzen Thema scheint mir diese Seite zu sein: https://24timezones.com/time-zones. Die Tabelle dort listet 200 verschiedene Zeitzonen auf. Hier sind diejenigen, die für uns relevant sind:
| Akronym | Zeitzone | Ort | UTC Diff. | GMT Diff. |
|---|---|---|---|---|
| CEST | Central European Summer Time | Frankfurt, Sommerzeit | UTC+2 | GMT+2 |
| CET | Central European Time | Frankfurt, Normalzeit | UTC+1 | GMT+1 |
| EDT | Eastern Daylight Time | New York, Normalzeit | UTC-4 | GMT-4 |
| EEST | Eastern European Summer Time | Zypern, Sommerzeit | UTC+3 | GMT+3 |
| EET | Eastern European Time | Zypern, Normalzeit | UTC+2 | GMT+2 |
| EST | Eastern Standard Time | New York, Normalzeit | UTC-5 | GMT-5 |
| ET | Eastern Time | New York | UTC-5/UTC-4 | GMT-5/GMT-4 |
| GMT | Greenwich Mean Time | London, Normalzeit | UTC+0 | GMT+0 |
| UTC | Coordinated Universal Time | London, Normalzeit | UTC | GMT |
Man beachte, die normale Zeitverschiebung von New York ist -5 Stunden im Sommer -4, also eine Stunde 'weniger', während die von Frankfurt +1 ist oder von MQ +2, aber im Sommer +2 bzw. +3, also eine Stunde 'mehr', wenn man rein auf die Ziffern schaut. Lassen Sie sich davon nicht verwirren, denken Sie an die Beispiele!
Schauen wir uns nun an, was die Zeitstempel der ersten und letzten Notierungen eines Demokontos von MQ um ein Wochenende herum sind: Im M1-Chart von "EURUSD" aktivieren wir zunächst die Periodentrennung, drücken dann im Chart die Eingabetaste und geben jeweils das Datum des Montags im Format tt.mm.jjjj (nicht MQ-Datumsformat) ein. Dann verschieben Sie das Chart mit der Maus ein wenig nach rechts. Der Balken mit der senkrechten Linie ist nun der erste der neuen Woche und der Balken links davon ist der letzte der vergangenen Woche. Hier sehen Sie die Daten des letzten Balkens vom Freitag und des ersten Balkens nach dem Wochenende:
Die Wochenenden rund um die Zeitumstellung im Herbst 2020:
| Sommer-EU | Sommer-EU | Sommer-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU |
|---|---|---|---|---|---|---|---|---|---|
| Sommer-US | Sommer-US | Sommer-US | Sommer-US | Sommer-US | Winter-US | Winter-US | Winter-US | Winter-US | Sommer-US |
| Fr. | Mo. | Fr. | Mo. | Fr. | Mo. | Fr. | Mo. | Fr. | Mo. |
| 2020.10.16 | 2020.10.19 | 2020.10.23 | 2020.10.26 | 2020.10.30 | 2020.11.02 | 2021.03.05 | 2021.03.08 | 2021.03.12 | 2021.03.15 |
| 23:54 | 00:05 | 23:54 | 00:05 | 22:54 | 00:02 | 23:54 | 00:03 | 23:54 | 00:00 |
| 1,1716 | 1,17195 | 1,18612 | 1,18551 | 1,16463 | 1,16468 | 1,19119 | 1,19166 | 1,19516 | 1,19473 |
| 1,17168 | 1,17208 | 1,18615 | 1,18554 | 1,16477 | 1,16472 | 1,19124 | 1,19171 | 1,19521 | 1,19493 |
| 1,1716 | 1,1718 | 1,18596 | 1,18529 | 1,16462 | 1,16468 | 1,19115 | 1,19166 | 1,19514 | 1,19473 |
| 1,1716 | 1,17188 | 1,18598 | 1,18534 | 1,16462 | 1,16472 | 1,1912 | 1,19171 | 1,19519 | 1,19491 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 29 | 22 | 35 | 48 | 30 | 3 | 33 | 2 | 23 | 25 |
| 4 | 11 | 2 | 6 | 2 | 61 | 1 | 38 | 1 | 29 |
Und hier die Wochenenden rund um die Zeitumstellung im Frühjahr 2021:
| Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Winter-EU | Sommer-EU | Sommer-EU | Sommer-EU |
|---|---|---|---|---|---|---|---|---|---|
| Winter-US | Winter-US | Winter-US | Sommer-US | Sommer-US | Sommer-US | Sommer-US | Sommer-US | Sommer-US | Sommer-US |
| Fr. | Mo. | Fr. | Mo. | Fr. | Mo. | Fr. | Mo. | Fr. | Mo. |
| 2021.03.05 | 2021.03.08 | 2021.03.12 | 2021.03.15 | 2021.03.19 | 2021.03.22 | 2021.03.26 | 2021.03.29 | 2021.04.02 | 2021.04.05 |
| 23:54 | 00:03 | 23:54 | 00:00 | 22:54 | 00:00 | 22:54 | 00:07 | 23:54 | 00:03 |
| 1,19119 | 1,19166 | 1,19516 | 1,19473 | 1,19039 | 1,18828 | 1,17924 | 1,17886 | 1,17607 | 1,17543 |
| 1,19124 | 1,19171 | 1,19521 | 1,19493 | 1,19055 | 1,18835 | 1,17936 | 1,17886 | 1,17608 | 1,17543 |
| 1,19115 | 1,19166 | 1,19514 | 1,19473 | 1,19038 | 1,18794 | 1,17922 | 1,17884 | 1,17607 | 1,17511 |
| 1,1912 | 1,19171 | 1,19519 | 1,19491 | 1,19044 | 1,18795 | 1,17933 | 1,17886 | 1,17608 | 1,17511 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 33 | 2 | 23 | 25 | 41 | 43 | 17 | 3 | 2 | 3 |
| 1 | 38 | 1 | 29 | 1 | 20 | 5 | 68 | 28 | 79 |
Interessant und für mich nicht ganz nachvollziehbar ist die Tatsache, dass die letzten Notierungen vor dem Wochenende manchmal um 23:00 Uhr (22:54 Uhr), in der Regel aber um 24:00 Uhr (23:54 Uhr) eintreffen, die ersten Notierungen aber immer um 00:00 Uhr. Dies führt bei einer rein stündlichen Betrachtung manchmal zu einem "Preisloch" von einer Stunde (Schließen um 23:00 Uhr, Öffnen um 00:00 Uhr), während der Devisenmarkt am Freitag immer um 17:00 Uhr (New Yorker Zeit) schließt und am Sonntag immer um 17:00 Uhr (New Yorker Zeit) öffnet. Schauen wir uns speziell die Wochenenden an, die umgestellt werden, und berechnen wir die entsprechende Zeit in den anderen Zeitzonen, die für uns relevant sind:
| Datum |
| Datum letzter Fr. |
|
|
| Datum |
|
|
|
|
| letzter m1 Balken | nächster m1 Balken |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Umstellung US |
| NY-Zeit | NY-GMT | GMT | Umstellung EU |
| CET-GMT | CET | EET-GMT | EET | von MQ | von MQ | |
|
| Sommer-US | Fr, 16. Okt 20 | 17:00 | GMT + 4 | 21 |
| Sommer-EU | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Sommer-US | So, 18. Okt 20 | 17:00 | GMT + 4 | 21 |
| Sommer-EU | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:05 |
|
| Sommer-US | Fr, 23. Okt 20 | 17:00 | GMT + 4 | 21 | 25.10.20 | Sommer-EU | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Sommer-US | So, 25. Okt 20 | 17:00 | GMT + 4 | 21 |
| Winter-EU | GMT + 1 | 22 | GMT + 2 | 23 |
| 00:05 |
| 01.11.20 | Sommer-US | Fr, 30. Okt 20 | 17:00 | GMT + 4 | 21 |
| Winter-EU | GMT + 1 | 22 | GMT + 2 | 23 | 22:54 |
|
|
| Winter-US | So, 1. Nov 20 | 17:00 | GMT + 5 | 22 |
| Winter-EU | GMT + 1 | 23 | GMT + 2 | 24 |
| 00:02 |
|
| Winter-US | Fr, 6. Nov 20 | 17:00 | GMT + 5 | 22 |
| Winter-EU | GMT + 1 | 23 | GMT + 2 | 24 | 23:54 |
|
|
| Winter-US | So, 8. Nov 20 | 17:00 | GMT + 5 | 22 |
| Winter-EU | GMT + 1 | 23 | GMT + 2 | 24 |
| 00:03 |
| 14.03.21 | Winter-US | Fr, 12. Mrz 21 | 17:00 | GMT + 5 | 22 |
| Winter-EU | GMT + 1 | 23 | GMT + 2 | 24 | 23:54 |
|
|
| Sommer-US | So, 14. Mrz 21 | 17:00 | GMT + 4 | 21 |
| Winter-EU | GMT + 1 | 22 | GMT + 2 | 23 |
| 00:00 |
|
| Sommer-US | Fr, 26. Mrz 21 | 17:00 | GMT + 4 | 21 | 28.03.21 | Winter-EU | GMT + 1 | 22 | GMT + 2 | 23 | 22:54 |
|
|
| Sommer-US | So, 28. Mrz 21 | 17:00 | GMT + 4 | 21 |
| Sommer-EU | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:07 |
|
| Sommer-US | Fr, 2. Apr 21 | 17:00 | GMT + 4 | 21 |
| Sommer-EU | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Sommer-US | So, 4. Apr 21 | 17:00 | GMT + 4 | 21 |
| Sommer-EU | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:03 |
In der/den Woche(n), in denen die Uhren in der EU und den USA nicht beide die lokale Sommerzeit bzw. Standardzeit anzeigen, öffnet der Devisenmarkt in New York am Sonntag um 23:00 Uhr EET und schließt am Freitag um 23:00 Uhr EET. Verschiedene Broker und auch die Demokonten von MQ stellen jedoch immer die ersten Kurse am Sonntag um 24:00 Uhr (oder Montag um 00:00 Uhr). Nun könnte man meinen, dass nicht mit der ersten Umstellung, sondern der Zeitstempel der Notierungen immer der zweiten Zeitumstellung folgt. Dann müssten aber am Freitag die letzten Kurse vor Schließung des Devisenmarktes einen Zeitstempel von kurz vor 24:00 haben, denn nur dann gibt es die vollen 24*5=120 Stunden, aber so fehlt eine Stunde. Das wirft die Frage auf, wann die Stunde fehlt: am Freitag vor dem Wochenende oder am Sonntag danach?
Da die Schlusskurse der Woche die wichtigeren sind als die erste Handelsstunde am Sonntag, kann man davon ausgehen, dass, wenn am Freitag die letzten Kurse von kurz vor 23:00 Uhr sind, die nächsten aber erst um 24:00 oder 00:00 Uhr, die erste Stunde des Devisenmarktes fehlt, nämlich die vom Sonntag 23:00-24:00, nicht aber die letzte, also die vom Freitag 23:00-24:00. Hätten die ersten Kurse jedoch einen Zeitstempel von Sonntag kurz nach 23:00, wäre es nicht nur recht einfach, die Zeitumstellung zu erkennen, sondern auch zu wissen, wann der Forex-Markt wieder schließt (5d*24h=120h nach der Eröffnung am Sonntag), wenn man eine vorsichtige Strategie verfolgt, die alle Positionen vor dem Wochenende schließt. Nun wie gesagt, einfach kann jeder.
Zunächst überlegen wir, welche Annahmen wir treffen können. Im Strategie-Tester haben wir nur TimeCurrent(). Damit ermitteln wir GMT oder UTC, sodass wir dann problemlos alle Zeiten anderer Zeitzonen berechnen können. Vorbehaltlich möglicher Feiertage oder anderer Gründe, die sich auf die Zeiten für das Öffnen und Schließen des Forex-Marktes in den USA auswirken, gehen wir davon aus:
- Der Devisenmarkt schließt am Freitag um 17:00 Uhr New Yorker Zeit.
- Der Devisenmarkt öffnet am Sonntag um 17:00 Uhr New Yorker Zeit.
- Er ist normalerweise für (5*24=) 120 Stunden geöffnet und für (2*24=) 48 Stunden geschlossen.
- Fehlen Stunden zwischen Fr. 17:00 und So. 17:00 Uhr, dann fehlen die Kurse am Sonntag bis zum ersten Kurs und nicht am Freitag nach dem letzten eingegangenen Kurs.
- Eingehende Kurse (egal mit welchem Zeitstempel) sind immer aktuell (und nicht z.B. 1 Stunde alt).
- Der Broker ändert seine Politik der Zeitumstellung nicht, wie es zuletzt war, so war es auch vorher für seine historischen Kurse.
Ausblick
Wir haben nun die Funktionen, oder genauer gesagt Makro-Substitutionen, definiert, die wir später verwenden werden, und die Bedingungen geklärt, um im nächsten Artikel "Umgang mit Zeit Teil 2: Die Funktionen" die Funktionen zu entwickeln, die für uns die GMT aus jeder beliebigen Zeit berechnen werden.
Angehängt ist DealingwithTimePart1.mqh, das die hier besprochenen Codeteile enthält. Er wird im zweiten Artikel um die erwähnten Funktionen erweitert.
Bitte schreiben Sie Vorschläge, Kommentare und Hinweise in den Kommentarbereich des Artikels.
Übersetzt aus dem Englischen von MetaQuotes Ltd.
Originalartikel: https://www.mql5.com/en/articles/9926
Grafiken in der Bibliothek DoEasy (Teil 83): Die Klasse des abstrakten grafischen Standardobjekts
Kombinatorik und Wahrscheinlichkeitsrechnung für den Handel (Teil III): Das erste mathematische Modell
Umgang mit Zeit (Teil 2): Die Funktionen
Grafiken in der Bibliothek DoEasy (Teil 82): Die Umgestaltung von Bibliotheksobjekten und Kollektion von grafischen Objekten
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.