Início Indicador técnico Postagem

Calendário Econômico: Monitoramento e Cache para Testes de Estratégia no MetaTrader 5

Anexo
53393.zip (32.58 KB, Baixar 0 vezes)

Para resumir tudo: o calendário econômico embutido no MetaTrader 5 não está (completamente) sincronizado com as cotações históricas.

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

Uma vez formadas, as barras permanecem inalteradas, incluindo seus timestamps. Por outro lado, o calendário econômico fornece informações sobre eventos (passados, presentes e futuros) de acordo com o fuso horário atual do servidor. Muitos corretores seguem um cronograma de fuso horário específico, incluindo a ativação e desativação do horário de verão, o que pode fazer com que os timestamps dos eventos históricos estejam deslocados em até 1 hora em relação às barras associadas, durante cerca de metade do ano.

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

Considerando que as notícias vêm de diferentes países com seus próprios horários de verão e que seu servidor pode estar localizado em uma região com outro cronograma, o horário das liberações de notícias pode "pular" visualmente para frente e para trás nos gráficos de maneira peculiar (por exemplo, por várias semanas na primavera e no outono).

Tudo isso pode não parecer tão importante online, 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 tester do MetaTrader, mas muitos traders gostam de operar com notícias, e todos os outros que não estão interessados devem acompanhar as notícias para simplesmente se afastar do mercado antes que ele fique agitado durante esses eventos. Portanto, realizar testes de estratégia com o calendário é essencial. É por isso que faz muito sentido exportar o calendário para um armazenamento externo (arquivo, banco de dados) e depois importá-lo para o tester. Uma dessas ferramentas de arquivamento para a experiência com o calendário no tester foi apresentada no livro de algotrading.

Entramos em um problema de desincronização das cotações históricas com os eventos históricos. Para simplificar, esse problema foi deixado sem resolução no livro.

Agora, a situação foi solucionada graças à versão estendida do CalendarCache.mqh e do indicador CalendarMonitorCachedTZ.mq5. Esta é 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ários é feito em segundo plano - na outra biblioteca pública TimeServerDST.mqh. Para entender melhor como a correção de horários funciona, você pode usar o script CalendarCSVForDates.mq5 e comparar arquivos CSV com e sem correção lado a lado.

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

#include <TimeServerDST.mqh> // incluindo antes do cache do calendário habilita o suporte à correção de fuso horário
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

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

Quando o indicador é anexado a um gráfico online com CalendarCacheFile vazio, ele funciona com o calendário embutido em tempo real.

Quando o indicador é executado com um nome específico em 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. Este é o estágio em que os timestamps devem/podem ser corrigidos (veja 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 embutido. Isso é especialmente útil para o tester.

O Monitor do Calendário no tester lê eventos do cache

Por favor, não se esqueça que o tester requer especificar arquivos adicionais, neste caso - o arquivo de calendário online preparado, na diretiva #property tester_file OU você deve colocar o arquivo de calendário na pasta comum C:/Users/<Usuário>/AppData/Roaming/MetaQuotes/Terminal/Common/.

Claro, o cache também pode ser carregado em um EA durante testes de retrocessos e otimizações.

A string de entrada FixCachedTimesBySymbolHistory é processada da seguinte forma.

Se estiver vazia, o indicador salva o cache sem correções de horário.

Para habilitar 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 dos fusos horários históricos do servidor. Ele funciona com base no histórico de cotações H1, preferencialmente "XAUUSD" ou "EURUSD".

Com a ajuda dessa entrada, apenas algumas linhas são 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 timestamps, e sua implementação utiliza os internos do TimeServerDST.mqh.

O método deve ser chamado online apenas (não no tester).

Normalmente, o método deve ser chamado em objetos de cache preenchidos a partir do calendário embutido, logo após o preenchimento. Caso contrário, se o cache for carregado de um arquivo de calendário, ou se o método já foi chamado anteriormente, o conteúdo do cache pode já estar ajustado. Então você aplicaria uma correção sobre a correção e obteria timestamps errados.

O segundo parâmetro (true) instrui o método a registrar os limites das alterações aplicadas no log. Algo assim:

Correção de horário iniciada em 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 um horário e ID de um evento onde uma nova discrepância foi detectada, o deslocamento do horário do servidor no evento e qual diferença deve ser aplicada a todos os timestamps subsequentes para eliminar o viés no horário do servidor no momento do cache do calendário.

Os arquivos mqh anexados (CalendarFilter.mqh, CalendarCache.mqh, QuickSortStructT(Ref).mqh) contêm correções e melhorias em comparação com suas versões originais do livro.

Atualizações

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

22.11.2024 - pequenas correções e melhorias em CalendarCache.mqh.

Publicações relacionadas

Comentário (0)