Optimisez vos Backtests avec un Calendrier Économique Synchronisé sur MetaTrader 5

Pour faire court : le calendrier économique intégré de MetaTrader 5 n’est pas (complètement) synchronisé avec les cotations historiques.

Les cotations sont marquées avec des timestamps selon les fuseaux horaires en vigueur sur le serveur au moment de la formation de chaque barre correspondante.

Une fois que les barres sont formées, elles restent inchangées, y compris leurs timestamps. En revanche, le calendrier économique fournit des informations sur des événements (passés, présents et futurs) liés au fuseau horaire actuel du serveur. Comme de nombreux courtiers respectent un calendrier de fuseau horaire spécifique, y compris les changements d’heure d’été, les timestamps des événements historiques peuvent être décalés d’une heure par rapport aux barres associées, pendant environ la moitié de l’année.

De plus, certains courtiers modifient les fuseaux horaires de manière plus radicale que le simple changement d’heure d’été. Les cotations historiques peuvent alors sembler décalées de plusieurs heures à gauche ou à droite par rapport à l’heure des événements économiques qui se sont initialement produits, mais qui sont maintenant rapportés par le calendrier dans le fuseau horaire mis à jour du serveur.

Étant donné que les nouvelles proviennent de différents pays avec leurs propres horaires d’heure d’été, et que votre serveur peut être situé dans une région avec un autre calendrier, l’heure des publications de nouvelles peut visuellement « sauter » en avant et en arrière sur les graphiques, même de manière plus étrange (par exemple, pendant plusieurs semaines au printemps et à l’automne).

Tout cela ne semble pas si important en ligne, mais que faire si nous voulons tester une stratégie basée sur les nouvelles ?

Oui, vous pouvez dire que le calendrier n’est pas pris en charge dans le testeur MetaTrader de manière native, mais de nombreux traders aiment trader les nouvelles, et tous les autres doivent suivre les nouvelles pour simplement se retirer du marché avant qu’il ne devienne fou pendant les annonces. C’est pourquoi le backtesting avec le calendrier est important. C’est pourquoi il est très logique d’exporter le calendrier vers un stockage externe (fichier, base de données) puis de l’importer dans le testeur. Un de ces outils d’archivage pour vivre l’expérience du calendrier dans le testeur a été présenté dans le livre sur l’algotrading.

Et ici, nous tombons sur le problème de désynchronisation des cotations historiques avec les événements historiques. Pour simplifier, ce problème a été laissé non résolu dans le livre.

Maintenant, il est résolu grâce à la version étendue de CalendarCache.mqh et l’indicateur de démonstration CalendarMonitorCachedTZ.mq5. C’est juste une version légèrement modifiée de CalendarMonitorCached.mq5 du livre.

L’indicateur surveille les événements d’actualité et met à jour dynamiquement un tableau sur le graphique avec plusieurs événements passés et à venir.

Tout le travail lié à la correction temporelle se fait en coulisses - dans l’autre bibliothèque publique TimeServerDST.mqh. Pour mieux comprendre comment fonctionne la correction temporelle, vous pouvez utiliser le script CalendarCSVForDates.mq5 et comparer les fichiers CSV avec et sans correction côte à côte.

Et voici comment la bibliothèque est intégrée dans les codes sources des deux programmes - le script et cet indicateur.

#include <TimeServerDST.mqh> // l'inclusion avant le cache de calendrier permet le support de correction de fuseau horaire
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

Comme dans l’indicateur original, il y a l’entrée de chaîne CalendarCacheFile, où vous pouvez fournir un nom de fichier de calendrier pour l’écriture ou la lecture.

Lorsque l’indicateur est attaché à un graphique en ligne avec un CalendarCacheFile vide, il fonctionne avec le calendrier intégré à la volée.

Lorsque l’indicateur est exécuté avec un nom spécifique dans CalendarCacheFile et que le fichier n’existe pas, l’indicateur exporte les enregistrements du calendrier dans le fichier de cache (crée le fichier) et se termine. C’est à ce moment que les timestamps doivent/p peuvent être corrigés (voir FixCachedTimesBySymbolHistory ci-dessous).

Lorsque l’indicateur est exécuté avec un nom de fichier de cache existant dans CalendarCacheFile, il charge le cache et travaille avec cette copie de la même manière qu’avec le calendrier intégré. Cela est particulièrement utile pour le testeur.

Le Moniteur de Calendrier dans le testeur lit les événements depuis le cache

Veuillez ne pas oublier que le testeur nécessite de spécifier des fichiers supplémentaires, dans notre cas - le fichier de calendrier en ligne préparé, dans la directive #property tester_file OU vous devez placer le fichier de calendrier dans le dossier commun C:/Users/<User>/AppData/Roaming/MetaQuotes/Terminal/Common/.

Bien sûr, le cache peut également être chargé dans un EA pendant les backtests et les optimisations.

La chaîne d’entrée FixCachedTimesBySymbolHistory est traitée de la manière suivante.

Si elle est vide, l’indicateur sauvegarde le cache sans corrections temporelles.

Pour activer les corrections temporelles lors de l’exportation, vous devez spécifier un symbole, qui sera utilisé pour la détection empirique des fuseaux horaires historiques du serveur. Il fonctionne sur la base de l’historique des cotations H1, de préférence "XAUUSD" ou "EURUSD".

Avec l’aide de cette entrée, seules quelques lignes sont ajoutées dans la nouvelle version de l’indicateur :

         if(StringLen(FixCachedTimesBySymbolHistory))
            cache[].adjustTZonHistory(FixCachedTimesBySymbolHistory, true);

La méthode adjustTZonHistory a été spécifiquement introduite dans la classe CalendarCache pour les ajustements des timestamps et son implémentation utilise les internes de TimeServerDST.mqh.

La méthode doit être appelée en ligne uniquement (pas dans le testeur).

Normalement, la méthode doit être appelée sur des objets de cache remplis à partir du calendrier intégré, immédiatement après le remplissage. Sinon, si le cache est chargé à partir d’un fichier de calendrier, ou si la méthode a déjà été appelée auparavant, le contenu du cache pourrait déjà avoir été ajusté. Ensuite, vous appliquerez une correction sur une correction et obtiendrez de faux timestamps.

Le second paramètre (true) indique à la méthode d’écrire les limites des changements appliqués dans le journal. Quelque chose comme ça :

La correction temporelle a commencé à 2021.07.19 00:30:00
2021.07.19 00:30:00: 148786 -10800 diff=-3600
2021.11.08 01:50:00: 135918 -7200 OK
2022.03.14 04:30:00: 161085 -10800 diff=-3600
2022.11.07 04:00:00: 165962 -7200 OK
2023.03.13 01:50:00: 168500 -10800 diff=-3600
2023.11.06 01:50:00: 169270 -7200 OK
2024.03.11 01:50:00: 181258 -10800 diff=-3600
2024.11.04 02:30:00: 208469 -7200 OK

Chaque ligne contient une heure et un ID d’événement où une nouvelle divergence a été détectée, le décalage horaire du serveur à l’événement, et quelle différence doit être appliquée à tous les timestamps suivants afin d’éliminer le biais dans l’heure du serveur au moment de la mise en cache du calendrier.

Les fichiers mqh joints (CalendarFilter.mqh, CalendarCache.mqh, QuickSortStructT(Ref).mqh) contiennent des corrections et des améliorations par rapport à leurs versions originales du livre.

Mises à jour

11.11.2024 - petite correction et mises à jour dans CalendarFilter.mqh, CalendarCache.mqh;

22.11.2024 - petites corrections et améliorations dans CalendarCache.mqh.

Optimisez vos Backtests avec un Calendrier Économique Synchronisé sur MetaTrader 5

Articles connexes