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

Las cotizaciones se marcan con marcas de tiempo de acuerdo con las zonas horarias que estaban en vigor en el servidor en el momento de la formación de cada barra correspondiente.

Una vez formadas las barras, éstas permanecen invariables, incluidas sus marcas de tiempo. Por otro lado, el calendario económico proporciona información sobre acontecimientos (pasados, presentes y futuros) vinculados a la zona horaria actual del servidor. Dado que muchos corredores se adhieren a un horario de zona horaria específico, incluyendo la activación y desactivación del modo de ahorro de luz diurna, las marcas de tiempo de los eventos históricos pueden estar desplazadas 1 hora con respecto a las barras asociadas, durante aproximadamente la mitad de cada año.

Por otra parte, a veces los corredores cambian las zonas horarias de forma más radical que el simple cambio del horario de verano. En ese caso, las cotizaciones históricas pueden aparecer desplazadas varias horas a la izquierda o a la derecha con respecto a la hora de los acontecimientos económicos que se produjeron originalmente en ellas, pero ahora el calendario las informa en la zona horaria actualizada del servidor.

Teniendo en cuenta que las noticias proceden de diferentes países con sus propios horarios DST y que su servidor puede estar situado en una región con otro horario, la hora de los comunicados de prensa puede "saltar" visualmente de un lado a otro en los gráficos incluso de forma más peculiar (por ejemplo, durante varias semanas en primavera y en otoño).

Todo esto no parece tan importante online, pero ¿y si queremos probar una estrategia basada en noticias?

Sí, se puede decir que el calendario no está soportado en MetaTrader tester de forma nativa, pero a muchos traders les gusta operar con noticias y todos los demás que no lo hacen deberían seguir las noticias para simplemente apartarse del mercado antes de que se vuelva loco durante las noticias. Así que el backtesting con el calendario es importante. Por eso es muy lógico exportar el calendario a un almacenamiento externo (archivo, base de datos) y luego importarlo al probador. Una de estas herramientas de archivo para la experiencia de calendario en el probador se presentó en el libro algotrading.

Y aquí nos encontramos con el problema de la desincronización de las citas históricas con los eventos históricos. En aras de la simplicidad, este problema se ha dejado sin resolver en el libro.

Ahora está resuelto gracias a la versión extendida de CalendarCache.mqh y el indicador CalendarMonitorCachedTZ.mq5. Se trata de una versión ligeramente modificada de CalendarMonitorCached.mq5 del libro.

El indicador monitoriza los eventos de noticias y actualiza dinámicamente una tabla en el gráfico con varios eventos pasados y próximos.

Todo el trabajo relacionado con la corrección de la hora se realiza entre bastidores - en la otra librería pública TimeServerDST.mqh. Para entender mejor cómo funciona la corrección de la hora se puede utilizar el scriptCalendarCSVForDates.mq5 y comparar archivos CSV con y sin corrección.

Y así es como la lib está incrustada en los códigos fuente de ambos programas - el script y este indicador.

#include <TimeServerDST.mqh> // la inclusión antes de la caché del Calendario permite la corrección de la zona horaria
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

Al igual que en el indicador original, existe la cadena de entrada CalendarCacheFile, donde se puede proporcionar un nombre de cal-file para escribir o leer.

Cuando el indicador se adjunta a un gráfico en línea con CalendarCacheFile vacío, funciona con el calendario incorporado sobre la marcha.

Cuando el indicador se ejecuta con un nombre específico en CalendarCacheFile y el archivo no existe, el indicador exporta los registros del calendario al archivo caché (crea el archivo) y sale. Esta es la etapa en la que las marcas de tiempo deben/pueden ser corregidas (ver FixCachedTimesBySymbolHistory más abajo).

Cuando el indicador se ejecuta con un nombre de archivo de caché existente en CalendarCacheFile, carga la caché y trabaja con esta copia de la misma manera que con el calendario incorporado. Esto es específicamente útil para el probador.

Por favor, no olvide que el tester requiere especificar archivos adicionales, en nuestro caso - el cal-file online preparado, en la directiva #property tester_file O debería colocar el cal-file en la carpeta común C:/Users/<Usuario>/AppData/Roaming/MetaQuotes/Terminal/Common/.

Por supuesto, la caché también se puede cargar en un EA durante backtests y optimizaciones.

La cadena de entrada FixCachedTimesBySymbolHistory se procesa de la siguiente manera.

Si está vacía, el indicador guarda la caché sin correcciones de tiempo.

Para habilitar las correcciones horarias durante la exportación debe especificar un símbolo, que se utilizará para la detección empírica de las zonas horarias históricas del servidor. Funciona basándose en el historial de cotizaciones H1, preferiblemente "XAUUSD" o "EURUSD".

Con la ayuda de esta entrada, sólo un par de líneas se añaden en la nueva versión del indicador:

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

El método adjustTZonHistory fue introducido específicamente en la clase CalendarCache para ajustes de timestamps y su implementación utiliza internos de TimeServerDST.mqh.

El método debe ser llamado sólo en línea (no en el probador).

Normalmente, el método debe ser llamado en objetos de caché rellenados desde el calendario incorporado, justo después del rellenado. De lo contrario, si la caché se carga desde un archivo cal, o si el método ya se ha llamado antes, el contenido de la caché podría estar ya ajustado. Entonces se aplicará ajuste sobre ajuste y se obtendrán marcas de tiempo erróneas.

El segundo parámetro(true) indica al método que escriba los límites de los cambios aplicados en el registro. Algo así

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 línea contiene la hora y el ID de un evento en el que se detectó una nueva discrepancia, el desplazamiento de la hora del servidor en el evento, y qué diferencia debe aplicarse a todas las marcas de tiempo posteriores para eliminar el sesgo en la hora del servidor en el momento del almacenamiento en caché del calendario.

Actualizaciones

11.11.2024 - pequeñas correcciones y actualizaciones en CalendarFilter.mqh, CalendarCache.mqh;

22.11.2024 - pequeñas correcciones de errores y mejoras en CalendarCache.mqh.