Calendario Económico: Monitoreo y Almacenamiento para Backtesting en MetaTrader 5

Para resumirlo de manera sencilla: el calendario económico integrado en MetaTrader 5 no está (completamente) sincronizado con las cotizaciones históricas.

Las cotizaciones están marcadas con marcas de tiempo de acuerdo con las zonas horarias que estaban en efecto en el servidor en el momento de la formación de cada barra correspondiente.

Una vez que se forman las barras, permanecen inalteradas, incluyendo sus marcas de tiempo. Por otro lado, el calendario económico proporciona información sobre eventos (pasados, presentes y futuros) vinculados a la zona horaria actual del servidor. Dado que muchos brokers siguen un horario de zona horaria específico, que incluye la activación y desactivación del horario de verano, las marcas de tiempo de los eventos históricos pueden estar desplazadas por 1 hora respecto a las barras asociadas, durante aproximadamente la mitad de cada año.

Aparte de eso, los brokers a veces cambian las zonas horarias de manera más radical que simplemente cambiar el horario de verano. Las cotizaciones históricas pueden aparecer desplazadas varias horas a la izquierda o a la derecha en relación con el momento de los eventos económicos que originalmente ocurrieron, pero que ahora se reportan en el calendario con la zona horaria actualizada del servidor.

Dado que las noticias provienen de diferentes países con sus propios horarios de verano y tu servidor puede estar ubicado en una región con otro horario, el tiempo de las publicaciones de noticias puede "saltar" visualmente hacia adelante y hacia atrás en los gráficos incluso de manera más peculiar (por ejemplo, durante varias semanas en primavera y otoño).

Todo esto no parece tan importante en línea, pero ¿qué pasa si queremos probar una estrategia basada en noticias?

Podrías decir que el calendario no es compatible de forma nativa en el tester de MetaTrader, pero muchos traders disfrutan 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 publicaciones. Así que el backtesting con el calendario es importante. Es por eso que es muy lógico exportar el calendario a un almacenamiento externo (archivo, base de datos) y luego importarlo al tester. Una de estas herramientas de archivo para la experiencia de calendario en el tester se presentó en el libro de algotrading.

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

Ahora está solucionado gracias a la versión extendida de CalendarCache.mqh y el indicador de demostración CalendarMonitorCachedTZ.mq5. Esta es solo una versión ligeramente modificada de CalendarMonitorCached.mq5 del libro.

El indicador monitorea eventos de noticias y actualiza dinámicamente una tabla en el gráfico con varios eventos pasados y futuros.

Todo el trabajo relacionado con la corrección de tiempo se realiza en segundo plano - en la otra biblioteca pública TimeServerDST.mqh. Para entender mejor cómo funciona la corrección de tiempo, se puede utilizar el script  CalendarCSVForDates.mq5  y comparar archivos CSV con y sin corrección lado a lado.

Y aquí se muestra cómo la biblioteca se incorpora en el código fuente de ambos programas - el script y este indicador.

#include <TimeServerDST.mqh> // incluyendo antes de Calendar cache habilita el soporte de corrección de zona horaria
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

Como en el indicador original, hay una entrada de cadena CalendarCacheFile, donde puedes proporcionar un nombre de archivo para escribir o leer.

Cuando el indicador se adjunta a un gráfico en línea con un CalendarCacheFile vacío, funciona con el calendario integrado en tiempo real.

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

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 integrado. Esto es especialmente útil para el tester.

Por favor, no olvides que el tester requiere especificar archivos adicionales, en nuestro caso - el archivo de calendario en línea preparado, en la directiva #property tester_file O deberías colocar el archivo en la carpeta común C:/Users/<Usuario>/AppData/Roaming/MetaQuotes/Terminal/Common/.

Por supuesto, la caché también puede ser cargada en un EA durante pruebas de retroceso 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 correcciones de tiempo durante la exportación, deberías especificar un símbolo, que se usará para la detección empírica de las zonas horarias históricas del servidor. Funciona basado en el historial de cotizaciones H1, preferiblemente "XAUUSD" o "EURUSD".

Con la ayuda de esta entrada, solo se agregan un par de líneas 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 marcas de tiempo y su implementación utiliza los internos de TimeServerDST.mqh.

El método debe ser llamado en línea únicamente (no en el tester).

Normalmente, el método debe ser llamado sobre objetos de caché llenados desde el calendario integrado, justo después de la carga. De lo contrario, si la caché se carga desde un archivo de calendario, o si el método ya ha sido llamado antes, el contenido de la caché podría ya estar ajustado. Entonces aplicarás un arreglo sobre otro arreglo y obtendrás marcas de tiempo incorrectas.

El segundo parámetro (true) instruye al método para escribir los límites de los cambios aplicados en el registro. Algo así como esto:

La corrección de tiempo comenzó en 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 un tiempo y ID de un evento donde se detectó una nueva discrepancia, el desfase horario del servidor en el evento y qué diferencia debe aplicarse a todas las marcas de tiempo posteriores para eliminar el sesgo en el tiempo del servidor en el momento del almacenamiento en caché del calendario.

Actualizaciones

11.11.2024 - corrección de errores menores y actualizaciones en CalendarFilter.mqh, CalendarCache.mqh;

22.11.2024 - correcciones menores y mejoras en CalendarCache.mqh.