Economic Calendar Monitor and Cache for Backtesting on History - indicatore per MetaTrader 5

Le quotazioni sono contrassegnate da timestamp in base ai fusi orari in vigore sul server al momento della formazione di ogni barra corrispondente.

Una volta formate, le barre rimangono invariate, compresi i timestamp. Il calendario economico, invece, fornisce informazioni sugli eventi (passati, presenti e futuri) legati al fuso orario attuale del server. Poiché molti broker rispettano uno specifico fuso orario, compresa l'attivazione e la disattivazione della modalità di ora legale, i timestamp degli eventi storici possono essere spostati di un'ora rispetto alle barre associate, per circa la metà di ogni anno.

Inoltre, a volte i broker cambiano i fusi orari in modo più radicale rispetto alla semplice attivazione della DST. Le quotazioni storiche possono quindi apparire spostate di diverse ore a sinistra o a destra rispetto all'ora degli eventi economici che si sono originariamente verificati su di esse, ma sono ora riportate dal calendario nel fuso orario aggiornato del server.

Tenendo conto del fatto che le notizie provengono da diversi Paesi con un proprio orario DST e che il vostro server può trovarsi in una regione con un altro orario, l'orario delle notizie rilasciate può visivamente "saltare" avanti e indietro sui grafici anche in modo più particolare (ad esempio, per diverse settimane in primavera e in autunno).

Tutto questo non sembra così importante online, ma cosa succede se vogliamo testare una strategia basata sulle notizie?

Sì, si può dire che il calendario non è supportato in modo nativo nel tester di MetaTrader, ma a molti trader piace fare trading sulle notizie e tutti gli altri che non lo fanno dovrebbero seguire le notizie per allontanarsi semplicemente dal mercato prima che si scateni durante le notizie. Quindi il backtesting con il calendario è importante. Per questo motivo è molto logico esportare il calendario in un archivio esterno (file, database) e poi importarlo nel tester. Uno di questi strumenti di archiviazione per l'esperienza del calendario nel tester è stato presentato nel libro algotrading.

E qui ci imbattiamo nel problema della desincronizzazione delle citazioni storiche con gli eventi storici. Per semplicità, questo problema è stato lasciato irrisolto nel libro.

Ora è stato risolto grazie alla versione estesa di CalendarCache.mqh e all'indicatore di presentazione CalendarMonitorCachedTZ.mq5. Si tratta di una versione leggermente modificata di CalendarMonitorCached.mq5 del libro.

L'indicatore monitora gli eventi di cronaca e aggiorna dinamicamente una tabella sul grafico con diversi eventi passati e futuri.

Tutto il lavoro relativo alla correzione dell'ora viene svolto dietro le quinte, nell'altra libreria pubblica TimeServerDST.mqh. Per capire meglio come funziona la correzione dell'ora si può utilizzare lo scriptCalendarCSVForDates.mq5 e confrontare i file CSV con e senza correzione.

Ecco come la libreria è incorporata nel codice sorgente di entrambi i programmi: lo script e questo indicatore.

#include <TimeServerDST.mqh> // l'inclusione prima della cache del Calendario abilita il supporto per la correzione del fuso orario
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

Come nell'indicatore originale, è presente la stringa di input CalendarCacheFile, in cui è possibile fornire un nome di file di calendario da scrivere o leggere.

Quando l'indicatore è collegato a un grafico online con CalendarCacheFile vuoto, funziona con il calendario integrato al volo.

Quando l'indicatore viene eseguito con un nome specifico in CalendarCacheFile e il file non esiste, l'indicatore esporta i record del calendario nel file della cache (crea il file) ed esce. Questa è la fase in cui i timestamp devono/possono essere corretti (si veda FixCachedTimesBySymbolHistory più avanti).

Quando l'indicatore viene eseguito con un nome di file di cache esistente in CalendarCacheFile, carica la cache e lavora con questa copia allo stesso modo del calendario integrato. Questo è particolarmente utile per i tester.

Non dimenticate che il tester deve specificare dei file aggiuntivi, nel nostro caso il file di calendario online preparato, nella direttiva #property tester_file OPPURE dovete collocare il file di calendario nella cartella comune C:/Users/<User>/AppData/Roaming/MetaQuotes/Terminal/Common/.

Naturalmente, la cache può essere caricata in un EA durante i backtest e le ottimizzazioni.

La stringa di input FixCachedTimesBySymbolHistory viene elaborata nel modo seguente.

Se è vuota, l'indicatore salva la cache senza correzioni temporali.

Per abilitare le correzioni dell'ora durante l'esportazione è necessario specificare un simbolo, che verrà utilizzato per il rilevamento empirico dei fusi orari storici del server. Funziona in base allo storico delle quotazioni H1, preferibilmente "XAUUSD" o "EURUSD".

Con l'aiuto di questo input, nella nuova versione dell'indicatore sono state aggiunte solo un paio di righe:

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

Il metodo adjustTZonHistory è stato introdotto specificamente nella classe CalendarCache per la regolazione dei timestamp e la sua implementazione utilizza i dati interni di TimeServerDST.mqh.

Il metodo deve essere chiamato solo online (non nel tester).

Normalmente il metodo dovrebbe essere richiamato sugli oggetti della cache riempiti dal calendario integrato, subito dopo il riempimento. Altrimenti, se la cache viene caricata da un file di calendario o se il metodo è già stato chiamato in precedenza, il contenuto della cache potrebbe essere già stato modificato. In tal caso, si applicherà una correzione su una correzione e si otterranno timestamp errati.

Il secondo parametro(true) indica al metodo di scrivere i confini delle modifiche applicate nel log. Qualcosa del genere:

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

Ogni riga contiene l'ora e l'ID di un evento in cui è stata rilevata una nuova discrepanza, l'offset dell'ora del server al momento dell'evento e la differenza che deve essere applicata a tutti i timestamp successivi per eliminare la distorsione dell'ora del server al momento della memorizzazione nella cache del calendario.

Aggiornamenti

11.11.2024 - piccola correzione di bug e aggiornamenti in CalendarFilter.mqh, CalendarCache.mqh;

22.11.2024 - piccole correzioni e miglioramenti in CalendarCache.mqh.