TimeServerDaylightSavings - Skript für den MetaTrader 5

Dieses Skript führt die Funktion TimeServerDaylightSavings() ein, die bei den eingebauten Funktionen fehlt, die nur TimeDaylightSavings() für den lokalen Computer bereitstellen. Darüber hinaus enthält die beigefügte mqh-Datei einige andere hilfreiche servergebundene zeitbezogene Funktionen, die es Ihnen insbesondere ermöglichen, herauszufinden, ob Ihr Broker generell Sommerzeitumstellungen verwendet.

All dies basiert auf einer empirischen Analyse der Kursverläufe Ihres Brokers. Die ganze Idee ist im Algotrading-Buch im Abschnitt über die Sommerzeit (DST) beschrieben. Kurz gesagt, die Methode analysiert die Statistiken der Wochenöffnungszeiten und leitet daraus die GMT-Offsets Ihres Brokers ab. Zwei ausgeprägte Maxima in der Statistik der Offsets, wenn sie auf benachbarte Stunden entfallen, entsprechen höchstwahrscheinlich der Standardzeit ("Winter") und der Sommerzeit ("Sommer").

Eigentlich ist dieses Skript eine verfeinerte und erweiterte Version des im Buch vorgestellten Skripts. Insbesondere die Versionen ab Oktober 2024 enthalten eine wichtige Fehlerkorrektur: Die Öffnungszeiten des wöchentlichen Handels werden vom US-Markt ermittelt, der seinerseits von der Sommerzeitumstellung gemäß der US-Zeitzone (EST, UTC-5, Standard-Winterzeit <--> EDT, UTC-4, Sommerzeit) betroffen ist. Deshalb ist es wichtig, den Effekt der US-Sommerzeit zu eliminieren, um einen kontinuierlichen natürlichen Zeitfluss das ganze Jahr über zu erhalten - das wurde in der Korrektur getan. Die ganze Anerkennung geht an amrali.

Bitte beachten Sie, dass in der nördlichen und südlichen Hemisphäre die Zeitzonen in umgekehrter Richtung angepasst werden: in der nördlichen Hemisphäre wird im "Frühling" (März oder April) eine Stunde hinzugefügt und im "Herbst" (Oktober oder November) abgezogen, während es in der südlichen Hemisphäre umgekehrt ist (weil dort alle Jahreszeiten vertauscht sind).

Aufgrund der Besonderheit der Analyse wird empfohlen, den Code für den liquidesten Forex-Ticker auszuführen, was in der Regel EURUSD ist.

Hier ist die API:

// Serverzeitzone und aktuelle Sommerzeitinformationen
struct ServerTimeZone  // nach historischer Analyse der Wochenöffnungszeiten
{
   int offsetGMT;      // Zeitzonenabweichung in Sekunden gegenüber UTC/GMT für die aktuelle Woche
   int offsetDST;      // Sommerzeitkorrektur in Sekunden (in offsetGMT enthalten, wie in MQL5)
   bool supportDST;    // Sommerzeitänderungen werden in den Anführungszeichen erkannt
};

// Schätzung der Zeitzone des Servers und des Sommerzeitmodus aus dem Verlauf der H1-Kurse
ServerTimeZone TimeServerZone(
  const datetime srvtime = 0,     // standardmäßig die aktuelle Zeit, kann aber auch einen Zeitpunkt in der Vergangenheit angeben
  const int threshold = THRESHOLD,
  const double lookupYears = 0.0, // standardmäßig alle verfügbaren Balken, ansonsten scheinen 3 Jahre zu reichen
  const string symbol = NULL)     // standardmäßig das Symbol des aktuellen Diagramms

// Schätzung der Serverzeit DST-Modus-Korrektur (in Sekunden)
int TimeServerDaylightSavings(const datetime srvtime = 0,
  const int threshold = THRESHOLD, const double lookupYears = 0.0, const string symbol = NULL);

// Schätzung des Zeitzonen-Offsets des Servers (in Sekunden)
int TimeServerGMTOffsetHistory(const datetime srvtime = 0,
  const int threshold = THRESHOLD, const double lookupYears = 0.0, const string symbol = NULL);

// Abschätzung, ob der Server für die Sommerzeit aktiviert ist (true/false)
bool TimeServerDaylightSavingsSupported(const datetime srvtime = 0,
  const int threshold = THRESHOLD, const double lookupYears = 0.0, const string symbol = NULL);

// Analog zur Funktion TimeGMTOffset() für Handelsserver, Differenz in Sekunden
int TimeServerGMTOffset(); // TimeGMT() - TimeTradeServer()

Die Funktionen TimeServerDaylightSavings(), TimeServerGMTOffsetHistory(), TimeServerDaylightSavingsSupported() sind nur Wrapper für TimeServerZone(), wenn Sie also mehr als eine Eigenschaft benötigen, ist es besser, die letztere zu verwenden und Werte aus der Struktur ServerTimeZone zu lesen.

Alle diese Funktionen nehmen als erstes Argument die Serverzeit, zu der Sie das entsprechende Merkmal erhalten möchten (in der Gegenwart oder in der Vergangenheit). Wird die Serverzeit auf 0 gesetzt (Standard), wird das Ergebnis für den aktuellen Zeitpunkt zurückgegeben.

Mit dem 2-ten Argument threshold können Sie die Empfindlichkeit der Algorithmen einstellen. Standardmäßig ist es 52/4, was einem Viertel des Jahres entspricht, das für die Entscheidungsfindung benötigt wird (Erkennung der Zeitzone ohne mögliche Beeinträchtigung durch kurze Wochen vor/nach den Feiertagen). Andererseits verhindert diese Einstellung die sofortige Erkennung von Ad-hoc-Zeitzonenänderungen (falls Ihr Broker sich irgendwann dazu entschließen sollte, dies zu tun). Sie sollten den Schwellenwert auf 0 setzen, damit die Algorithmen Änderungen so schnell wie möglich erkennen können.

Die Funktion TimeServerGMTOffset() verwendet keine History-Analyse, sondern berechnet den Offset direkt über MQL5-Funktionen (wie TimeGMT() - TimeTradeServer()).

Das Testskript gibt z. B. alle erfassten Daten im Protokoll aus:

1 ~ Built-in functions ~
TimeLocal()=2024.10.05 00:39:01 / ok
TimeCurrent()=2024.10.05 00:38:59 / ok
TimeTradeServer()=2024.10.05 00:39:01 / ok
TimeGMT()=2024.10.04 21:39:01 / ok
TimeGMTOffset()=-10800 / ok
TimeDaylightSavings()=0 / ok
2 ~ Add-on over built-in functions ~
TimeServerGMTOffset()=-10800 / ok
3 ~ Estimation of server TZ with DST based on week opening hours in history ~
TimeServerDaylightSavings()=-3600 / ok
    [offsetGMT] [offsetDST] [supportDST]
[0]      -10800       -3600         true

In diesem Fall wird festgestellt, dass sich der Server in der Sommerzeit befindet, während der lokale Computer nicht in der Sommerzeit ist.

Bitte denken Sie daran, dass die Systemuhren des lokalen Computers und des Servers normalerweise leicht unterschiedliche Zeiten (Sekunden und sogar Minuten) anzeigen können, selbst wenn sie sich in der gleichen Zeitzone befinden. Beachten Sie auch, dass die eingebaute Funktion TimeTradeServer() eine synthetische Zeit zurückgibt: Es ist die Zeit des Servers mit stündlicher Genauigkeit, aber sie übernimmt die Stundenbruchteile von der lokalen Uhr. Dies wird in MQL5 so gemacht, um die Konvertierung zwischen Zeitzonen zu vereinfachen - TimeLocal(), TimeGMT() wird auch im "lokalen Format" zurückgegeben, und die Zeit des Handelsservers.

Sie können den detaillierten Ausdruck der analysierten Daten durch eine Präprozessoranweisung aktivieren:

#define  PRINT_DST_DETAILS

die in Ihrem Code vor dem Include platziert werden sollte:

#include "TimeServerDST.mqh"

Hier ist ein Beispiel für Details im Protokoll:

Got 20023 H1 bars, ~834 days
Week opening hours stats:
30  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 83 54  0
Time Zone changes (UTC±X before/after weekstart):
            [weekstart]    [before] [DSTb] [after] [DSTa]
[0] 2021.07.25 00:00:00 -2147483648  false      -1  false
[1] 2021.11.08 00:00:00           0   true       0  false
[2] 2022.03.14 00:00:00           0  false       0   true
[3] 2022.11.07 00:00:00           0   true       0  false
[4] 2023.03.13 00:00:00           0  false       0   true
[5] 2023.11.06 00:00:00           0   true       0  false
[6] 2024.03.11 00:00:00           0  false       2  false
3 different timezones detected in quotes, 1 DST candidates
Server time offset: UTC+2 STD
TimeServerDaylightSavings()=-3600 / ok

Bitte lassen Sie das Skript in Ihrer Umgebung laufen und posten Sie die resultierenden Logs in der Diskussion.

Aktualisierungen

2024.10.10 - Fehlerbehebung: US-Sommerzeitumstellungen (die in die Öffnungszeitstatistiken eingriffen) werden vor der Hauptanalyse aus der Zeitleiste entfernt.

2024.10.27 - Serverzeit von Interesse und minimaler wöchentlicher Statistikschwellenwert wurden als Argumente für alle Funktionen hinzugefügt; TimeServerGMTOffsetEmpiric() wurde umbenannt in TimeServerGMTOffsetHistory().

2024.10.29 - kleiner Bugfix, um die angeforderte Zeit in den Nachschlagezeitraum einzubeziehen.

2024.10.30 - DST im TimeZoneChange Array korrigiert; die Suche wird jetzt anhand des srvtime Parameters durchgeführt, wenn er angegeben ist.

2024.11.01 - automatische Anpassung der Berechnungen bei der Anwendung auf Edelmetalle hinzugefügt, was zuverlässigere Ergebnisse in Wochen liefern kann, in denen die US-Sommerzeit und die EU-Sommerzeit nicht synchron sind.

2024.11.04 - Die Online-Erkennung der Sommerzeitumstellung wurde verbessert.

2024.11.07 - Zwischenspeicherung von Zeitzonen-/Sommerzeit-Änderungen für Massenabfragen in der Historie für Indikatoren oder Backtesting von Wirtschaftsereignissen hinzugefügt.

2024.11.08 - Die Caching-Leistung wurde durch ein kleines Code-Refactoring optimiert.

2024.11.16 - 1-Stunden-Anpassung für von Metallen abgeleitete Zeitstempel durch amrali.

2024.11.17 - Refactoring und Korrekturen von amrali: Cache-Rebuilds für Online-Anfragen an Wochenenden eliminiert, 48h Vorlauf für die Erkennung von TZ-Änderungen an Wochenenden (mit möglicher DST-Umstellung) hinzugefügt, Sonntag 00:00 als Grenze für Zeitzonen verwendet (statt 1. Takt einer Woche).

2024.11.20 - Standardschwellenwert auf 1 geändert (ein Gleichgewicht zwischen prompter Erkennung von Zeitzonenänderungen und Eliminierung von Fehlalarmen in Nicht-Standard-Wochen, z.B. nach Feiertagen); neue Funktionen für die Zeitformatierung hinzugefügt, einschließlich Zeitzonen-Offsets und Sommerzeit (siehe TimeZoneFmt.mqh); andere kleine Verbesserungen.