Economic Calendar Monitor and Cache for Backtesting on History - indicador para MetaTrader 5

As cotações são marcadas com registros de data e hora de acordo com os fusos horários que estavam em vigor no servidor no momento da formação de cada barra correspondente.

Depois que as barras são formadas, elas permanecem inalteradas, incluindo seus carimbos de data/hora. Por outro lado, o calendário econômico fornece informações sobre eventos (passados, presentes e futuros) vinculados ao fuso horário atual do servidor. Como muitas corretoras seguem um cronograma específico de fuso horário, incluindo a ativação e desativação do modo de economia de luz do dia, os registros de data e hora dos eventos históricos podem ser deslocados em 1 hora em relação às barras associadas, por cerca de metade de cada ano.

Além disso, os corretores às vezes mudam os fusos horários de forma mais radical do que apenas mudando o horário de verão. As cotações históricas podem, então, parecer deslocadas várias horas para a esquerda ou para a direita em relação ao horário dos eventos econômicos que ocorreram originalmente nelas, mas agora são relatadas pelo calendário no fuso horário atualizado do servidor.

Levando em conta que as notícias vêm de diferentes países com seus próprios horários de horário de verão e que seu servidor pode estar localizado em uma região com outro horário, o horário dos comunicados de imprensa pode "saltar" visualmente para frente e para trás nos gráficos, até mesmo de maneira mais peculiar (por exemplo, por várias semanas na primavera e no outono).

Tudo isso não parece ser tão importante on-line, mas e se quisermos testar uma estratégia baseada em notícias?

Sim, você pode dizer que o calendário não é suportado nativamente no testador do MetaTrader, mas muitos traders gostam de operar com notícias e todos os outros que não gostam devem acompanhar as notícias para simplesmente se afastar do mercado antes que ele enlouqueça durante as notícias. Portanto, o backtesting com o calendário é importante. É por isso que é muito lógico exportar o calendário para um armazenamento externo (arquivo, banco de dados) e depois importá-lo para o testador. Uma dessas ferramentas de arquivamento para a experiência do calendário no testador foi apresentada no livro algotrading.

E aqui nos deparamos com o problema da dessincronização de cotações históricas com eventos históricos. Por uma questão de simplicidade, esse problema foi deixado sem solução no livro.

Agora ele foi resolvido graças à versão ampliada do CalendarCache.mqh e ao indicador CalendarMonitorCachedTZ.mq5. Essa é apenas uma versão ligeiramente alterada do CalendarMonitorCached.mq5 do livro.

O indicador monitora eventos de notícias e atualiza dinamicamente uma tabela no gráfico com vários eventos passados e futuros.

Todo o trabalho relacionado à correção de horário é feito nos bastidores, na outra biblioteca pública TimeServerDST.mqh. Para entender melhor como funciona a correção de horário, é possível usar o scriptCalendarCSVForDates.mq5 e comparar os arquivos CSV com e sem correção lado a lado.

E aqui está como a biblioteca está incorporada nos códigos-fonte de ambos os programas - o script e esse indicador.

#include <TimeServerDST.mqh> // incluir antes do cache do Calendário permite o suporte à fixação de fuso horário
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

Como no indicador original, há a entrada de string CalendarCacheFile, na qual você pode fornecer um nome de arquivo de calendário para gravação ou leitura.

Quando o indicador é anexado a um gráfico on-line com o CalendarCacheFile vazio, ele funciona com o calendário interno em tempo real.

Quando o indicador é executado com um nome específico no CalendarCacheFile e o arquivo não existe, o indicador exporta os registros do calendário para o arquivo de cache (cria o arquivo) e sai. Esse é o estágio em que os registros de data e hora devem/podem ser corrigidos (consulte FixCachedTimesBySymbolHistory abaixo).

Quando o indicador é executado com um nome de arquivo de cache existente em CalendarCacheFile, ele carrega o cache e trabalha com essa cópia da mesma forma que com o calendário incorporado. Isso é especialmente útil para o testador.

Não se esqueça de que o testador precisa especificar arquivos adicionais, no nosso caso - o arquivo de calendário on-line preparado, na diretiva #property tester_file OU você deve colocar o arquivo de calendário na pasta comum C:/Users/<User>/AppData/Roaming/MetaQuotes/Terminal/Common/.

Obviamente, o cache também pode ser carregado em um EA durante backtests e otimizações.

A string de entrada FixCachedTimesBySymbolHistory é processada da seguinte forma.

Se estiver vazia, o indicador salvará o cache sem correções de tempo.

Para ativar as correções de horário durante a exportação, você deve especificar um símbolo, que será usado para a detecção empírica de fusos horários históricos do servidor. Ele funciona com base no histórico de cotações H1, de preferência "XAUUSD" ou "EURUSD".

Com a ajuda dessa entrada, apenas algumas linhas foram adicionadas à nova versão do indicador:

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

O método adjustTZonHistory foi especificamente introduzido na classe CalendarCache para ajustes de carimbos de data/hora e sua implementação usa os elementos internos do TimeServerDST.mqh.

O método deve ser chamado somente on-line (não no testador).

Normalmente, o método deve ser chamado em objetos de cache preenchidos a partir do calendário incorporado, logo após o preenchimento. Caso contrário, se o cache for carregado a partir de um arquivo de calendário ou se o método já tiver sido chamado antes, o conteúdo do cache já poderá estar ajustado. Então, você aplicará correção sobre correção e obterá registros de data e hora errados.

O segundo parâmetro(true) instrui o método a gravar os limites das alterações aplicadas no registro. Algo parecido com isto:

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

Cada linha contém a hora e o ID de um evento em que uma nova discrepância foi detectada, o deslocamento da hora do servidor no evento e a diferença que deve ser aplicada a todos os carimbos de data/hora subsequentes para eliminar a distorção na hora do servidor no momento do armazenamento em cache do calendário.

Atualizações

11.11.2024 - pequenas correções de bugs e atualizações em CalendarFilter.mqh, CalendarCache.mqh;

22.11.2024 - pequenas correções de bugs e melhorias no CalendarCache.mqh.