Laat ik het kort houden: de ingebouwde economische kalender van MetaTrader 5 is niet (volledig) gesynchroniseerd met de historische koersdata.
De koersen zijn gemarkeerd met tijdstempels die overeenkomen met de tijdzones die van kracht waren op de server op het moment dat elke bijbehorende bar werd gevormd.
Eenmaal gevormd blijven de bars onveranderd, inclusief hun tijdstempels. Aan de andere kant biedt de economische kalender informatie over gebeurtenissen (verleden, heden en toekomst) die zijn gekoppeld aan de huidige tijdzone van de server. Aangezien veel brokers zich aan een specifiek tijdzoneschema houden, inclusief het in- en uitschakelen van de zomertijd, kunnen de tijdstempels van historische gebeurtenissen met 1 uur verschoven zijn ten opzichte van de bijbehorende bars, gedurende ongeveer de helft van elk jaar.
Bovendien veranderen brokers soms de tijdzones drastischer dan alleen het overschakelen van zomertijd. Historische koersen kunnen dan enkele uren naar links of rechts zijn verschoven ten opzichte van het moment van de economische gebeurtenissen die oorspronkelijk op hen plaatsvonden, maar nu door de kalender worden gerapporteerd in de bijgewerkte tijdzone van de server.
Aangezien nieuws uit verschillende landen komt met hun eigen zomertijdschema's en je server zich in een regio kan bevinden met een ander schema, kunnen de tijden van nieuwspublicaties visueel "springen" op de grafieken, zelfs op een merkwaardige manier (bijvoorbeeld gedurende enkele weken in de lente en de herfst).
Dit lijkt misschien niet zo belangrijk online, maar wat als we een op nieuws gebaseerde strategie willen testen?
Ja, je kunt zeggen dat de kalender niet standaard wordt ondersteund in de MetaTrader tester, maar veel traders houden van het traden op nieuws en iedereen die dat niet doet, moet de nieuws volgen om simpelweg uit de markt te blijven voordat deze wild wordt tijdens nieuws. Daarom is backtesting met de kalender belangrijk. Het is dan ook heel logisch om de kalender naar een externe opslag (bestand, database) te exporteren en deze vervolgens in de tester te importeren. Een van dergelijke archiveringstools voor de kalender-in-tester ervaring werd gepresenteerd in het algotrading boek.
En hier stuiten we op het probleem van de desynchronisatie van historische koersen met historische gebeurtenissen. Ter vereenvoudiging is dit probleem in het boek onbehandeld gelaten.
Dit is nu opgelost dankzij de uitgebreide versie van CalendarCache.mqh en de showcase-indicator CalendarMonitorCachedTZ.mq5. Dit is gewoon een licht gewijzigde versie van CalendarMonitorCached.mq5 uit het boek.
De indicator houdt nieuwsgebeurtenissen in de gaten en werkt dynamisch een tabel op de grafiek bij met verschillende afgelopen en aankomende gebeurtenissen.
Alle werkzaamheden met betrekking tot tijdcorrectie worden achter de schermen gedaan - in de andere openbare bibliotheek TimeServerDST.mqh. Voor een beter begrip van hoe de tijdcorrectie werkt, kan men het script CalendarCSVForDates.mq5 gebruiken en CSV-bestanden met en zonder correctie naast elkaar vergelijken.
En hier is hoe de bibliotheek is ingebed in de broncodes van beide programma's - het script en deze indicator.
#include <TimeServerDST.mqh> // opnemen voordat de kalendercache tijdzonefix-up ondersteuning inschakelt #include <MQL5Book/CalendarFilterCached.mqh> #include <MQL5Book/CalendarCache.mqh>
Net als bij de oorspronkelijke indicator is er de string invoer CalendarCacheFile, waar je een naam voor het cal-bestand kunt opgeven voor schrijven of lezen.
Wanneer de indicator aan een online grafiek wordt gehecht met een lege CalendarCacheFile, werkt deze met de ingebouwde kalender in real-time.
Wanneer de indicator wordt uitgevoerd met een specifieke naam in CalendarCacheFile en het bestand bestaat niet, exporteert de indicator de kalenderrecords naar het cache-bestand (maakt het bestand aan) en verlaat deze. Dit is het stadium waarin de tijdstempels gecorrigeerd moeten/kunnen worden (zie FixCachedTimesBySymbolHistory hieronder).
Wanneer de indicator wordt uitgevoerd met een naam van een bestaand cache-bestand in CalendarCacheFile, laadt deze de cache en werkt met deze kopie op dezelfde manier als met de ingebouwde kalender. Dit is specifiek nuttig voor de tester.
Vergeet niet dat de tester aanvullende bestanden vereist, in ons geval - het voorbereide online cal-bestand, in de richtlijn #property tester_file OF je moet het cal-bestand in de gemeenschappelijke map plaatsen C:/Users/<User>/AppData/Roaming/MetaQuotes/Terminal/Common/.
Natuurlijk kan de cache ook in een EA worden geladen tijdens backtests en optimalisaties.
De invoerstring FixCachedTimesBySymbolHistory wordt als volgt verwerkt.
Als deze leeg is, slaat de indicator de cache op zonder tijdcorrecties.
Om tijdcorrecties tijdens export in te schakelen, moet je een symbool opgeven dat zal worden gebruikt voor empirische detectie van historische tijdzones van de server. Dit werkt op basis van de geschiedenis van H1-koersen, bij voorkeur "XAUUSD" of "EURUSD".
Met behulp van deze invoer worden slechts een paar regels toegevoegd in de nieuwe versie van de indicator:
if(StringLen(FixCachedTimesBySymbolHistory)) cache[].adjustTZonHistory(FixCachedTimesBySymbolHistory, true);
De methode adjustTZonHistory is specifiek geïntroduceerd in de CalendarCache klasse voor tijdstempelcorrecties en de implementatie maakt gebruik van internals van TimeServerDST.mqh.
De methode moet alleen online worden aangeroepen (niet in de tester).
Normaal gesproken moet de methode worden aangeroepen op cache-objecten die zijn gevuld vanuit de ingebouwde kalender, direct na het vullen. Anders, als de cache is geladen vanuit een cal-bestand, of als de methode eerder al is aangeroepen, kunnen de inhoud van de cache al zijn aangepast. Dan krijg je een fix op een fix en krijg je verkeerde tijdstempels.
De tweede parameter (true) instrueert de methode om veranderingen in de log te schrijven. Iets als dit:
Tijdcorrectie gestart op 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
Elke regel bevat een tijd en ID van een gebeurtenis waarbij een nieuwe discrepantie werd gedetecteerd, de tijdsverschil van de server op het moment van de gebeurtenis en welk verschil moet worden toegepast op alle volgende tijdstempels om de bias in de server tijd tijdens het cachen van de kalender te elimineren.
De bijgevoegde mqh-bestanden (CalendarFilter.mqh, CalendarCache.mqh, QuickSortStructT(Ref).mqh) bevatten bugfixes en verbeteringen vergeleken met hun originele versies uit het boek.
Updates
11.11.2024 - kleine bugfix en updates in CalendarFilter.mqh, CalendarCache.mqh;
22.11.2024 - kleine bugfixes en verbeteringen in CalendarCache.mqh.
Gerelateerde berichten
- PCA Synthetics: Automatische Coëfficiëntselectie voor MetaTrader 5
- iExposure Indicator: Beheer je Handelsposities Efficiënt met MetaTrader 5
- Efficiënt Grafische Objecten Kopiëren in MetaTrader 5 met ChartObjectsCopyPaste
- Efficiëntie Ratio (ER) Berekenen met de CEROnRingBuffer voor MetaTrader 5
- Verbeter je Handelsstrategieën met de ColorXADX Indicator voor MetaTrader 5