Economic Calendar Monitor and Cache for Backtesting on History - indicateur pour MetaTrader 5

Les cotations sont marquées d'un horodatage conforme aux fuseaux horaires en vigueur sur le serveur au moment de la formation de chaque barre correspondante.

Une fois les barres formées, elles restent inchangées, y compris leurs horodatages. D'autre part, le calendrier économique fournit des informations sur les événements (passés, présents et futurs) liés au fuseau horaire actuel du serveur. Étant donné que de nombreux courtiers respectent un fuseau horaire spécifique, y compris l'activation et la désactivation du mode d'heure d'été, les horodatages 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.

En outre, les courtiers changent parfois de fuseau horaire de manière plus radicale que le simple passage à l'heure d'été. Les cotations historiques peuvent alors apparaître décalées de plusieurs heures vers la gauche ou la droite par rapport à l'heure des événements économiques qui s'y sont produits à l'origine, mais qui sont désormais rapportés par le calendrier dans le fuseau horaire mis à jour du serveur.

Si l'on tient compte du fait que les nouvelles proviennent de différents pays ayant leur propre horaire et que votre serveur peut être situé dans une région ayant un autre horaire, l'heure des communiqués de presse peut visuellement "sauter" d'un côté à l'autre des graphiques, même de manière plus particulière (par exemple, pendant plusieurs semaines au printemps et à l'automne).

Tout cela ne semble pas très important en ligne, mais qu'en est-il si nous voulons tester une stratégie basée sur les actualités ?

Oui, vous pouvez dire que le calendrier n'est pas pris en charge nativement dans le testeur MetaTrader, mais de nombreux traders aiment négocier les nouvelles et tous ceux qui ne le font pas devraient suivre les nouvelles pour simplement s'écarter du marché avant qu'il ne s'emballe pendant les nouvelles. Le backtesting avec le calendrier est donc important. C'est pourquoi il est très logique d'exporter le calendrier vers un stockage externe (fichier, base de données) et de l'importer ensuite dans le testeur. L'un de ces outils d'archivage pour l'expérience du calendrier dans le testeur a été présenté dans le livre algotrading.

Nous nous heurtons ici au problème de la désynchronisation des citations historiques avec les événements historiques. Pour des raisons de simplicité, ce problème n'a pas été résolu dans le livre.

Il est maintenant résolu grâce à la version étendue de CalendarCache.mqh et à l'indicateur CalendarMonitorCachedTZ.mq5. Il s'agit d'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 de l'heure est effectué en coulisses - dans l'autre bibliothèque publique TimeServerDST.mqh. Pour mieux comprendre le fonctionnement de la correction de l'heure, vous pouvez utiliser le scriptCalendarCSVForDates.mq5 et comparer les fichiers CSV avec et sans correction, l'un à côté de l'autre.

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

#include <TimeServerDST.mqh> // l'inclusion avant le cache du calendrier permet la prise en charge de la correction des fuseaux horaires
#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 cal 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 cache (crée le fichier) et quitte. C'est à ce stade que les horodatages doivent/peuvent être corrigés (voir FixCachedTimesBySymbolHistory ci-dessous).

Lorsque l'indicateur est exécuté avec un nom de fichier-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é. Ceci est particulièrement utile pour les testeurs.

N'oubliez pas que le testeur doit spécifier des fichiers supplémentaires, dans notre cas - le fichier cal préparé en ligne, dans la directive #property tester_file OU vous devez placer le fichier cal 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 de temps.

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

Grâce à cette entrée, seules quelques lignes ont été 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 d'horodatage et son implémentation utilise les éléments internes de TimeServerDST.mqh.

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

Normalement, la méthode devrait être appelée sur les objets de cache remplis à partir du calendrier intégré, juste après le remplissage. Sinon, si le cache est chargé à partir d'un fichier cal, ou si la méthode a déjà été appelée auparavant, le contenu du cache pourrait être déjà ajusté. Dans ce cas, vous appliquerez correctif sur correctif et obtiendrez des horodatages erronés.

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

Time fix-up started at 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 l'heure et l'ID d'un événement où une nouvelle divergence a été détectée, le décalage horaire du serveur lors de l'événement et la différence à appliquer à tous les horodatages suivants afin d'éliminer le biais de l'heure du serveur au moment de la mise en cache du calendrier.

Mises à jour

11.11.2024 - petites corrections de bogues et mises à jour dans CalendarFilter.mqh, CalendarCache.mqh ;

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