Gestionando el Horario (Parte 1): Fundamentos
1 985
6
Qué hora
La sincronización precisa puede ser un elemento crucial en el trading. A la hora actual, ¿la bolsa de valores de Londres o Nueva York está ya abierta o sigue cerrada? ¿Cuándo comienza y finaliza el horario comercial para el trading en Fórex? Para un tráder que comercia de forma manual y en vivo, esto no supone un gran problema. Usando varias herramientas de Internet, las especificaciones de los instrumentos financieros y la propia hora, uno puede ver rápidamente cuándo es el momento adecuado para comerciar con la propia estrategia. Para algunos tráders que solo miran la evolución de los precios, y compran y venden cuando el desarrollo de estos les ofrece una señal, la hora en sí no es importante. Resulta diferente para los tráders que se dedican al 'scalping nocturno', que comercian después del cierre del mercado (de valores) en Nueva York y antes de que los mercados (de valores) en la UE se abran, o para aquellos que comercian específicamente, por ejemplo, sobre la 'ruptura de Londres' o de otra forma durante el tiempo de mayor rotación, o todos aquellos que negocian con acciones o futuros. Estos tráders no pueden seguir los horarios del bróker, sino que deben usar los horarios locales reales en los EE.UU., Japón, Londres, la UE o Moscú, en los que se abre o cierra la Bolsa respectiva o los horarios especiales en los que se comercia con un futuro especial.
Horario de verano, horario de invierno y compensación del bróker
Como ya hemos mencionado, los tráders que se sientan frente a la pantalla para comprar y vender pueden manejar fácilmente los diferentes horario, ya sea a través de Internet o usando determinadas funciones, los valores o relojes que el PC mantiene disponibles y que se pueden recuperar en cualquier momento con funciones MQL como TimeGMT(), TimeGMTOffset() y otros. La situación resulta diferente si uno quiere escribir y probar un programa comercial con datos históricos que operen en función del tiempo. En realidad, de forma análoga al comercio en vivo, la pregunta debería ser igual de fácil de responder.
A partir del UTC (Universal Coordinated Time) o del Greenich Mean Time (GMT, https://greenwichmeantime.com/what-is-gmt/), uno simplemente tendría que añadir el cambio geográfico de hora o el relacionado con el instrumento, y ya sabría qué hora es en qué lugar. Pero no resulta tan simple. Existe el cambio de horario de invierno a verano (DST o horario de verano), que, según la hora, suma o resta 1 hora. Sea como fuere, aunque no resulte uniforme, cada país o región tiene su propia definición, a veces constante durante años (UE y EE.UU.), y en ocasiones cambiante, como en el caso de Rusia, donde fue cancelada en 2014. En la UE, hubo un debate en 2018, incluida una encuesta sobre la cuestión de la abolición del cambio de hora anual (https://ec.europa.eu/germany/news/20180831-konsultation-sommerzeit_de), que reveló que una amplia mayoría de la población estaba a favor de la abolición, por lo que la Comisión presentó una propuesta legislativa para terminar con el cambio de horario (https://ec.europa.eu/germany/news/20180914-kommission-gesetzesvorschlag-ende-zeitumstellung_de), que, nuevamente, acabó en nada.
Como si eso no resultara suficientemente caótico, ahora los brókeres están añadiendo a la mezcla cómo definen su propia hora del servidor. En 2015, un bróker alemán me escribió:
- Hasta el 8 de marzo de 2015, la hora de nuestro servidor MT4 se establece como la hora de Londres ( = GMT ).
- Del 8 de marzo de 2015, hasta el 29 de marzo, se establece como CET ( GMT + 1 )
- A partir del 29 de marzo, el servidor se establece en la hora de Londres ( = GMT + 1 )
Es decir, el bróker alemán usa GMT + DST-USA, o (principalmente) la hora de Londres + DST de los EE. UU.; es decir, tenemos que pensar en eso primero, aunque las razones nos resulten incomprensibles, porque el comercio de divisas comienza a las 17:00 hora de Nueva York, y eso está sujeto al cambio de hora estadounidense. Como resultado, para alguien con sede en Frankfurt, el comercio de divisas a veces comienza a las 21:00, generalmente a las 22:00, y durante una o dos semanas en el otoño, a las 23:00.
Para nosotros, como tráders y clientes, esto se parece más a estar en un jardín de infancia. Todo el mundo hace lo que quiere y como quiere. Por consiguiente, el tráder o el desarrollador se enfrenta a muchos horarios diferentes, todos los cuales podrían resultar importantes; estos, además, deberían determinarse a partir de los 'recursos integrados' de MQL, pero, desafortunadamente, no sucede así si hablamos de un indicador, script o EA que se ejecuta en el simulador de estrategias.
Vamos a cambiar esto. Sin tener que preguntarle al bróker, determinaremos sus respectivos cambios de hora, de forma que podamos definir el GMT fácilmente en cualquier momento y antes de cualquier marca temporal en el simulador de estrategias y, posteriormente, por supuesto, cualquier otra hora local requerida como la hora de Nueva York. Además, como acaba de surgir en este contexto, también definiremos el tiempo restante que el mercado de divisas está aún abierto, para todos los tráders que quieran cerrar sus posiciones abiertas antes del fin de semana, si fuera necesario. Sin embargo, llegaremos a estas funciones solo en el segundo artículo, porque ahora debemos desarrollar algunas macrosustituciones para simplificar en las funciones mencionadas los cálculos y representaciones para el control.
Macrosustituciones
Todo lo que viene ahora está en el archivo de inclusión (adjunto) DealingWithTimePart1.mqh. Al principio de este archivo se encuentran varias macrosustituciones.
En primer lugar, hay algunos cambios de horario de diferentes regiones, para que no tenga usted que derivarlos o buscarlos una y otra vez:
//--- defines #define TokyoShift -32400 // always 9h #define NYShift 18000 // winter 17h=22h GMT: NYTime + NYshift = GMT #define LondonShift 0 // winter London offset #define SidneyShift -39600 // winter Sidney offset #define FfmShift -3600 // winter Frankfurt offset #define MoskwaShift -10800 // winter Moscow offset #define FxOPEN 61200 // = NY 17:00 = 17*3600 #define FxCLOSE 61200 // = NY 17:00 = 17*3600 #define WeekInSec 604800 // 60sec*60min*24h*7d = 604800 => 1 Week
Para una mejor comprensión, estaremos de acuerdo en que el GMT es un ancla de tiempo invariable, mientras que las diferentes horas locales, como Nueva York, Londres o Moscú, se distinguirán de aquella por una diferencia horaria variable y propia. Asimismo, también nos referiremos como variables a las diferencias horarias de verano o invierno. La razón es simple. Los signos de las diferencias temporales variables se definen de la manera que se aplica:
hora variable + diferencia de tiempo variable = GMT
Algunos ejemplos:
Moscú (16h) + diferencia con Moscú (-3h) = GMT (13h)
Hora de Nueva York (16h) + diferencia con Nueva York (+5h) = GMT (21h)
Hora de Nueva York (16h) + (diferencia con Nueva York (+5h) + DST_US(-1h)) = GMT (20h)
Hora de Frankfurt (16h) + (diferencia con Frankfurt (-1h) + DST_US(-1h)) = GMT (14h)
¡Cuidado con los paréntesis! Estos son importantes cuando las horas variables se calculan a partir de GMT:
Hora de Nueva York (16h) = GMT (20h) - (diferencia con Nueva York (+5h) + DST_US(-1h)) => 20 -(+5 + -1) = 20 - 5 +1 = 16h
Hora de Frankfurt (16h) = GMT (14h) - (diferencia con Frankfurt (-1h) + DST_US(-1h)) => 14 -( -1 + -1) = 14 +1 +1 = 16h
Créame, es una fuente eterna de errores de signos y malentendidos.
De esta forma, también MQL5 y el PC manejan las diferencias de hora como TimeGMTOffset(): TimeLocal() + TimeGMTOffset() = TimeGMT()) o TimeDaylightSavings(): TimeLocal() + TimeDaylightSavings() = invierno u hora local estándar del PC.
Finalmente, en esta parte se encuentran FxOpen y FxClose, así como la duración de una semana completa en segundos, WeekInSec, porque estas designaciones resultan más fáciles de comprender que si, por ejemplo, añadiéramos en el código de golpe 604800 a una variable.
Luego vienen dos simplificaciones sencillas de la salida de la variable. TOSTR(A) imprime el nombre de la variable y su valor: bastante agradable. Después va la matriz con las abreviaturas de los días de la semana. Se usa varias veces en el código desarrollado para este proyecto, y ayuda a ahorrar espacio en la línea, pero también se utiliza para la orientación de las marcas de tiempo calculadas:
#define TOSTR(A) #A+":"+(string)(A)+" " // Print (TOSTR(hGMT)); => hGMT:22 (s.b.) string _WkDy[] = // week days { "Su.", "Mo.", "Tu.", "We.", "Th.", "Fr.", "Sa.", "Su." };
Ahora, vamos a ceñirnos a alternativas para el cálculo de la hora que eviten el desvío cuando se asigne una hora a la estructura MQ MqlDateTime para leer un valor escalar. Se calculan directamente:
#define DoWi(t) ((int)(((t-259200)%604800)/86400)) // (int)Day of Week Su=0, Mo=1,... #define DoWs(t) (_WkDy[DoWi(t)]) // Day of Week as: Su., Mo., Tu., ....
DoWi(t) (Día de la Semana como entero) determina el día de la semana como un entero (Sunday:0, Monday:1, ...) mientras que DoWs(t) (Día de la Semana como string) retorna el día de la semana abreviado como texto usando DoWi(t) y la matriz _WkDy[]. Como la segunda parte del artículo tratará de las últimas y primeras horas de los fines de semana, estas macrosustituciones se usarán con más frecuencia.
#define SoD(t) ((int)((t)%86400)) // Seconds of Day #define SoW(t) ((int)((t-259200)%604800)) // Seconds of Week
SoD(t) (Segundos del día) retorna el número de segundos desde las 00:00 del tiempo transcurrido. So SoD(TimeCurrent()) calcula de esta forma sencilla la duración en segundos que ya existe en una vela de día. De manera similar, SoW(t) calcula el número de segundos desde el último domingo a las 00:00. De esta forma, resulta sencillo calcular el porcentaje de tiempo transcurrido (en segundos) y el tiempo restante de esta vela del día. Si dividimos este valor por 864 (=0.01*24*60*60), obtendremos el porcentaje del día ya transcurrido:
(double)SoD(D’20210817 15:34‘) / 864. = 64.86% 86400 - SoD(D’20210817 15:34‘) = Print("D'20210817 15:34': ", DoubleToString((double)SoD(D'20210817 15:34')/864.0, 2),"% ", 86400 - SoD(D’20210817 15:34‘),“ sec left“ );
Estos cálculos funcionan de la forma correspondiente (para quien lo necesite):
#define MoH(t) (int(((t)%3600)/60)) // Minute of Hour #define MoD(t) ((int)(((t)%86400)/60)) // Minute of Day 00:00=(int)0 .. 23:59=1439
La función ToD(t) retorna los segundos del día como tipo de datos "datetime". Esto evita los mensajes de advertencia del compilador en una u otra situación:
#define ToD(t) ((t)%86400) // Time of Day in Sec (datetime) 86400=24*60*60
La función HoW(to) retorna el número de horas que han pasado desde el domingo a las 00:00:
#define HoW(t) (DoW(t)*24+HoD(t)) // Hour of Week 0..7*24 = 0..168 0..5*24 = 0..120
Esto se puede usar para calcular la hora del día de forma sencilla, el resultado es un número entero, no una fecha:
#define HoD(t) ((int)(((t)%86400)/3600)) //Hour of Day: 2018.02.03 17:55 => 17
Lo mismo, solo que 'comercial' redondeado:
#define rndHoD(t) ((int)((((t)%86400)+1800)/3600))%24 // rounded Hour of Day 17:55 => 18
y de nuevo lo mismo como tipo datetime:
#define rndHoT(t) ((t+1800)-((t+1800)%3600)) // rounded Hour of Time: 2018.02.03 17:55:56 => (datetime) 2018.02.03 18:00:00
La hora de inicio del día como datetime, que de lo contrario tendría que determinarse adicionalmente con la llamada del marco temporal de día D1:
#define BoD(t) ((t)-((t)%86400)) // Begin of day 17.5 12:54 => 17.5. 00:00:00
La hora de inicio de la semana como datetime, que de lo contrario tendría que determinarse llamando el marco temporal semanal:
#define BoW(t) ((t)-((t-172800)%604800 - 86400)) // Begin of Week, Su, 00:00
Los siguientes fragmentos usan las estructuras y funciones de MQL, porque la conversión es demasiado complicada para mí (por ejemplo, a causa de los años bisiestos), pero siguen el mismo principio del formato anterior: las funciones temporales tienen nombres de principalmente tres letras o acrónimos, DoY, (=Día del año), MoY (mes del año) y YoY (año del año):
MqlDateTime tΤ; // hidden auxiliary variable: the Τ is a Greek characker, so virtually no danger int DoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.day_of_year); } int MoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.mon); } int YoY(const datetime t) {TimeToStruct(t,tΤ);return(tΤ.year); }
Aquí se encuentra todavía el cálculo de la semana del año según la definición de los EE.UU.:
int WoY(datetime t) //Su=newWeek Week of Year = nWeek(t)-nWeeks(1.1.) CalOneWeek:604800, Su.22:00-Su.22:00 = 7*24*60*60 = 604800 { return(int((t-259200) / 604800) - int((t-172800 - DoY(t)*86400) / 604800) + 1); // calculation acc. to USA }
(Más información sobre los cálculos semanales aquí: https://en.wikipedia.org/wiki/Week#Numbering)
Diferencias horarias estacionales y locales
Una vez declaradas y explicadas las simplificaciones requeridas por las funciones, y un poco más, vamos a preparar y mostrar un amplio campo de diferencias horarias locales y estacionales, y cómo los brókeres y MQL5 manejan estas. Comenzaremos con nuestro lenguaje de programación MQL5.
La hora en MQL5
La hora primera e inmediata es aquella con la que el bróker ofrece sus cotizaciones, reflejada en la hora de apertura de las barras, y se puede consultar con TimeCurrent() para la última cotización recibida. En muchos casos, y esto puede resultar sorprendente, esta hora es relativamente poco importante y solo sirve para clasificar las barras y los precios, y también las actividades comerciales en el tiempo. Por consiguiente, tiene su relevancia solo en el entorno del terminal y en el comercio en vivo, así como en el simulador de estrategias.
Luego está TimeTradeServer(): "Retorna la hora de cálculo actual del servidor comercial. A diferencia de la función TimeCurrent(), el cálculo de la hora se realiza en el terminal del cliente, y depende de los ajustes temporales en la computadora del usuario. "PERO: "Durante las pruebas en el simulador de estrategias, TimeTradeServer() se simula según los datos históricos, y siempre es igual a TimeCurrent(). "Por consiguiente, esta función no resultará de mucha ayuda a los programas que deban optimizarse para comerciar en vivo en el simulador de estrategias.
Lo mismo resulta cierto para TimeGMT() y TimeLocal(): "Durante la prueba en el simulador de estrategias, TimeGMT() siempre es igual a la hora del servidor simulado TimeTradeServer()", y esto es igual a TimeCurrent().
Esto también hace que TimeGMTOffset() resulte 'inútil' en el simulador de estrategias, porque TimeGMTOffset() = TimeGMT() - TimeLocal(), y eso es siempre y en todo momento cero. :(
Lo último que queda es TimeDaylightSavings(): "Retorna la corrección del horario de verano en segundos si se ha producido la transición a dicho horario. Depende de la configuración de la computadora del usuario. ... Si se ha producido la transición al horario de invierno (horario estándar), retornará 0."
Aquí está la impresión de una cuenta de demostración en vivo (MQ, como puede ver en la fecha, es actualmente el horario de verano en la UE y EE.UU. en el momento de la consulta):
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeCurrent: 10:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeTradeServer: 10:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeLocal: 09:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeGMT: 07:25
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeDaylightSavings: -3600 h: -1
2021.08.26 09:25:45.321 MasteringTime (EURUSD,M1) TimeGMTOffset: -7200 h: -2
y aquí tenemos la impresión de la misma cuenta en el simulador de estrategias (depuración):
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeCurrent: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeTradeServer: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeLocal: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeGMT: 23:54
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeDaylightSavings: 0 h: 0
2021.08.26 10:15:43.407 2021.06.18 23:54:59 TimeGMTOffset: 0 h: 0
Todas estas funciones no ayudan en el simulador de estrategias, solo en vivo. Entonces solo tenemos TimeCurrent() para calcular todas las demás horas por nosotros mismos, y eso con todo el desorden. Bueno, cualquiera puede hacerlo fácilmente ;)
Teóricamente, podríamos pensar que podemos obtener todo del bróker: cómo define, por ejemplo, las diferencias horarias para las marcas temporales de sus cotizaciones. Aquí tenemos, sin ir más lejos, la respuesta de Alpari:
(GMT+2/GMT +3 DST) y terminan el viernes a las 23:55:00, hora del servidor. Durante el verano,
el horario comercial se inicia a las 21:05 GMT del domingo, y durante el horario de invierno,
a las 22:05 GMT del domingo.
Resulta que esto es solo cierto en parte. En primer lugar, no se menciona el tiempo de transición en el que la UE y EE.UU. no son iguales en verano o en invierno y, en segundo lugar, los precios en este tiempo de transición, por ejemplo, el 26.3.2021, no termina a las 23:55, sino a las 22:55, antes y después de nuevo a las 23:55.
Pero antes de continuar, una pequeña descripción de las diferentes zonas horarias y sus acrónimos. Me parece que el sitio web más útil para profundizar en este tema es: https://24timezones.com/time-zones. El recuadro enumera 200 zonas horarias distintas. Estas son las que resultan relevantes para nosotros:
| Acrónimo | Zona horaria | Sitio web | Diferencia UTC | Diferencia GMT |
|---|---|---|---|---|
| CEST | Hora de verano de Europa Central | Frankfurt, hora de verano | UTC+2 | GMT+2 |
| CET | Hora de Europa Central | Frankfurt, hora normal | UTC+1 | GMT+1 |
| EDT | Hora del este | Nueva York, hora normal | UTC-4 | GMT-4 |
| EEST | Hora de verano de Europa del Este | Zypern, hora de verano | UTC+3 | GMT+3 |
| EET | Hora de Europa del Este | Zypern, hora normal | UTC+2 | GMT+2 |
| EST | Hora Estándar del Este | Nueva York, hora normal | UTC-5 | GMT-5 |
| ET | Hora del Este | Nueva York | UTC-5/UTC-4 | GMT-5/GMT-4 |
| GMT | Hora del Meridiano de Greenwich | Hora Estándar de Londres | UTC+0 | GMT+0 |
| UTC | Hora Universal Coordinada | Hora Estándar de Londres | UTC | GMT |
Tenga en cuenta que la diferencia horaria normal respecto a Nueva York es de -5 horas, en verano -4, una hora 'menos'; mientras que la de Frankfurt es +1, o respecto a MQ +2 (en verano es +2 y +3, respectivamente), así que una hora 'más', si nos fijamos únicamente en los números. No se confunda por eso, ¡recuerde los ejemplos!
Ahora, vamos a ver cuáles son las marcas temporales de la primera y la última cotización de una cuenta demo de MQ en un fin de semana: en el gráfico M1 de "EURUSD", primero activamos la separación de periodos, y luego presionamos Enter en el gráfico para introducir en cada caso la fecha del lunes en el formato dd.mm.aaaa (no en el formato de fecha MQ). Luego desplazamos el gráfico un poco hacia la derecha con la ayuda del ratón. Ahora, la barra con la línea vertical será la primera de la nueva semana, y la barra a la izquierda será la última de la semana pasada. Estas serán las fechas de la última barra del viernes y de la primera barra después del fin de semana:
Fines de semana alrededor del cambio de hora en otoño de 2020:
| Verano-UE | Verano-UE | Verano-UE | Invierno-UE | Invierno-UE | Invierno-UE | Invierno-UE | Invierno-UE | Invierno-UE | Invierno-UE |
|---|---|---|---|---|---|---|---|---|---|
| Verano-EE.UU. | Verano-EE.UU. | Verano-EE.UU. | Verano-EE.UU. | Verano-EE.UU. | Invierno-EE.UU. | Invierno-EE.UU. | Invierno-EE.UU. | Invierno-EE.UU. | Verano-EE.UU. |
| Viernes | Lunes | Viernes | Lunes | Viernes | Lunes | Viernes | Lunes | Viernes | Lunes |
| 2020.10.16 | 2020.10.19 | 2020.10.23 | 2020.10.26 | 2020.10.30 | 2020.11.02 | 2021.03.05 | 2021.03.08 | 2021.03.12 | 2021.03.15 |
| 23:54 | 00:05 | 23:54 | 00:05 | 22:54 | 00:02 | 23:54 | 00:03 | 23:54 | 00:00 |
| 1,1716 | 1,17195 | 1,18612 | 1,18551 | 1,16463 | 1,16468 | 1,19119 | 1,19166 | 1,19516 | 1,19473 |
| 1,17168 | 1,17208 | 1,18615 | 1,18554 | 1,16477 | 1,16472 | 1,19124 | 1,19171 | 1,19521 | 1,19493 |
| 1,1716 | 1,1718 | 1,18596 | 1,18529 | 1,16462 | 1,16468 | 1,19115 | 1,19166 | 1,19514 | 1,19473 |
| 1,1716 | 1,17188 | 1,18598 | 1,18534 | 1,16462 | 1,16472 | 1,1912 | 1,19171 | 1,19519 | 1,19491 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 29 | 22 | 35 | 48 | 30 | 3 | 33 | 2 | 23 | 25 |
| 4 | 11 | 2 | 6 | 2 | 61 | 1 | 38 | 1 | 29 |
Y aquí los fines de semana alrededor del cambio de hora en la primavera de 2021:
| Invierno-UE | Invierno-UE | Invierno-UE | Invierno-UE | Invierno-UE | Invierno-UE | Invierno-UE | Verano-UE | Verano-UE | Verano-UE |
|---|---|---|---|---|---|---|---|---|---|
| Invierno-EE.UU. | Invierno-EE.UU. | Invierno-EE.UU. | Verano-EE.UU. | Verano-EE.UU. | Verano-EE.UU. | Verano-EE.UU. | Verano-EE.UU. | Verano-EE.UU. | Verano-EE.UU. |
| Viernes | Lunes | Viernes | Lunes | Viernes | Lunes | Viernes | Lunes | Viernes | Lunes |
| 2021.03.05 | 2021.03.08 | 2021.03.12 | 2021.03.15 | 2021.03.19 | 2021.03.22 | 2021.03.26 | 2021.03.29 | 2021.04.02 | 2021.04.05 |
| 23:54 | 00:03 | 23:54 | 00:00 | 22:54 | 00:00 | 22:54 | 00:07 | 23:54 | 00:03 |
| 1,19119 | 1,19166 | 1,19516 | 1,19473 | 1,19039 | 1,18828 | 1,17924 | 1,17886 | 1,17607 | 1,17543 |
| 1,19124 | 1,19171 | 1,19521 | 1,19493 | 1,19055 | 1,18835 | 1,17936 | 1,17886 | 1,17608 | 1,17543 |
| 1,19115 | 1,19166 | 1,19514 | 1,19473 | 1,19038 | 1,18794 | 1,17922 | 1,17884 | 1,17607 | 1,17511 |
| 1,1912 | 1,19171 | 1,19519 | 1,19491 | 1,19044 | 1,18795 | 1,17933 | 1,17886 | 1,17608 | 1,17511 |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 33 | 2 | 23 | 25 | 41 | 43 | 17 | 3 | 2 | 3 |
| 1 | 38 | 1 | 29 | 1 | 20 | 5 | 68 | 28 | 79 |
Interesante y no del todo comprensible para mí es el hecho de que a veces las últimas cotizaciones antes del fin de semana llegan alrededor de las 23:00 (22:54), pero generalmente a las 24:00 (23:54); las primeras cotizaciones, sin embargo, siempre llegan a las 00:00. Desde un punto de vista puramente horario, esto a veces crea un 'agujero de precios' de 1 hora (cierre a las 23:00, apertura a las 00:00), mientras que el mercado Fórex siempre cierra a las 17:00 (hora de Nueva York) los viernes, y siempre abre a las 17:00 (hora de Nueva York) el domingo. Vamos a mirar específicamente los fines de semana que cambian, y a calcular la hora respectiva en las otras zonas horarias que resultan relevantes para nosotros:
| Fecha |
| Fecha del último viernes |
|
|
| Fecha |
|
|
|
|
| última barra m1 | próxima barra m1 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Cambio US |
| Hora NY | NY-GMT | GMT | Cambio EU |
| CET-GMT | CET | EET-GMT | EET | de MQ | de MQ | |
|
| Verano-EE.UU. | Viernes, 16. Oct 20 | 17:00 | GMT + 4 | 21 |
| Verano-UE | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Verano-EE.UU. | Domingo, 18. Oct 20 | 17:00 | GMT + 4 | 21 |
| Verano-UE | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:05 |
|
| Verano-EE.UU. | Viernes, 23. Oct 20 | 17:00 | GMT + 4 | 21 | 25.10.20 | Verano-UE | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Verano-EE.UU. | Domingo, 25. Oct 20 | 17:00 | GMT + 4 | 21 |
| Invierno-UE | GMT + 1 | 22 | GMT + 2 | 23 |
| 00:05 |
| 01.11.20 | Verano-EE.UU. | Viernes, 30. Oct 20 | 17:00 | GMT + 4 | 21 |
| Invierno-UE | GMT + 1 | 22 | GMT + 2 | 23 | 22:54 |
|
|
| Invierno-EE.UU. | Domingo, 1. Nov 20 | 17:00 | GMT + 5 | 22 |
| Invierno-UE | GMT + 1 | 23 | GMT + 2 | 24 |
| 00:02 |
|
| Invierno-EE.UU. | Viernes, 6. Nov 20 | 17:00 | GMT + 5 | 22 |
| Invierno-UE | GMT + 1 | 23 | GMT + 2 | 24 | 23:54 |
|
|
| Invierno-EE.UU. | Domingo, 8. Nov 20 | 17:00 | GMT + 5 | 22 |
| Invierno-UE | GMT + 1 | 23 | GMT + 2 | 24 |
| 00:03 |
| 14.03.21 | Invierno-EE.UU. | Viernes, 12. Mzo 21 | 17:00 | GMT + 5 | 22 |
| Invierno-UE | GMT + 1 | 23 | GMT + 2 | 24 | 23:54 |
|
|
| Verano-EE.UU. | Domingo, 14. Mzo 21 | 17:00 | GMT + 4 | 21 |
| Invierno-UE | GMT + 1 | 22 | GMT + 2 | 23 |
| 00:00 |
|
| Verano-EE.UU. | Viernes, 26. Mzo 21 | 17:00 | GMT + 4 | 21 | 28.03.21 | Invierno-UE | GMT + 1 | 22 | GMT + 2 | 23 | 22:54 |
|
|
| Verano-EE.UU. | Domingo, 28. Mzo 21 | 17:00 | GMT + 4 | 21 |
| Verano-UE | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:07 |
|
| Verano-EE.UU. | Viernes, 2. Abr 21 | 17:00 | GMT + 4 | 21 |
| Verano-UE | GMT + 2 | 23 | GMT + 3 | 24 | 23:54 |
|
|
| Verano-EE.UU. | Domingo, 4. Abr 21 | 17:00 | GMT + 4 | 21 |
| Verano-UE | GMT + 2 | 23 | GMT + 3 | 24 |
| 00:03 |
En la(s) semana(s) en que los relojes de la UE y los EE.UU. no muestran el horario de verano local o el horario estándar respectivamente, el mercado de divisas en Nueva York abre el domingo a las 23:00 EET, y cierra el viernes a las 23:00 EET. Sin embargo, varios brókeres, así como las cuentas demo de MQ, siempre ofrecen las primeras cotizaciones el domingo a las 24:00 (o el lunes a las 00:00). Ahora, podríamos pensar que no es con el primer cambio, sino con la marca temporal de las cotizaciones que sigue el segundo cambio de horario. Luego, sin embargo, el viernes, los últimos cursos antes del cierre del mercado Fórex tendrían que tener una marca temporal poco anterior a las 24:00, porque solo entonces se encontrarán las 24*5=120 horas completas; pero entonces faltará una hora. Esto nos hace preguntarnos, ¿cuándo falta esa hora: el viernes anterior al fin de semana o el domingo posterior?
Como los precios de cierre de la semana son más importantes en comparación con la primera hora comercial del domingo, podemos suponer que si el viernes los últimos precios se dan poco antes de las 23:00, pero los siguientes se dan solo a las 24:00 o las 00:00, faltará la primera hora del mercado Fórex; la del domingo a las 23:00-24:00, pero no la última, a saber, la del viernes a las 23:00-24:00. En cualquier caso, si los primeros precios tuvieran una marca temporal del domingo poco después de las 23:00, resultaría bastante fácil no solo reconocer el cambio de hora, sino también saber cuándo el mercado Fórex cierra nuevamente (5d*24h=120h después de la apertura el domingo), si seguimos una estrategia cautelosa que cierre todas las posiciones antes del fin de semana. Bueno, como ya hemos dicho, cualquiera puede hacerlo.
Primero, vamos a considerar qué suposiciones podemos hacer. En el simulador de estrategias, solo tenemos TimeCurrent(). Con esto determinaremos GMT o UTC, de forma que podamos calcular fácilmente todas las horas de otras zonas horarias. Respecto a posibles días festivos u otros motivos que afecten a los horarios de apertura y cierre del mercado de divisas en USA, asumiremos que:
- El mercado Fórex cierra el viernes a las 17:00, hora de Nueva York.
- El mercado Fórex abre el domingo a las 17:00, hora de Nueva York.
- Normalmente, está abierto durante (5*24=) 120h y cerrado durante (2*24=) 48 h.
- Si faltan horas entre el viernes a las 17:00 y el domingo a las 17:00, luego faltarán cotizaciones el domingo hasta la primera cotización, y no el viernes después de la última cotización recibida.
- Las cotizaciones entrantes (sin importar la marca temporal) siempre están actualizadas (y no tienen una hora de antigüedad, por ejemplo).
- El bróker no modifica su política de cambio de hora, ya que fue la última, como era antes para sus cotizaciones históricas.
Panorámica
Ahora ya hemos definido las funciones, o más precisamente las macrosustituciones que usaremos más adelante, y hemos aclarado las condiciones para desarrollar en el próximo artículo ("Gestionando el Horario (Parte 2): Funciones") las funciones que calcularán GMT a partir de cualquier hora dada.
Adjuntamos DealingwithTimePart1.mqh, que contiene las partes del código analizadas aquí. El archivo será ampliado con las funciones mencionadas en el segundo artículo.
Por favor, no dude en escribir sus comentarios y sugerencias en la sección de comentarios al final del artículo.
Traducción del inglés realizada por MetaQuotes Ltd.
Artículo original: https://www.mql5.com/en/articles/9926
Gráficos en la biblioteca DoEasy (Parte 84): Clases herederas del objeto gráfico abstracto estándar
Cómo ser un mejor programador (parte 05): Aprendiendo a desarrollar más rápido
Gestionando el Horario (Parte 2): Funciones
Gráficos en la biblioteca DoEasy (Parte 83): Clase de objeto gráfico abstracto estándar
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
¿Puede un corredor hacer que las transacciones aparezcan en MT5 1 hora antes que el mercado real de Londres, por ejemplo? En mi caso, en meta trader 5 obtengo la hora de cada operación 1 hora antes de la hora de Londres, que es donde se ejecuta la operación.
Depende del símbolo forex cfd son negociables desde Su. 23:00 hasta el vie. 23:00 según horario y corredor
El horario en el terminal es el de la ubicación del servidor, es decir, que si el broker está ubicado en Londres, pero el servidor está en por ejemplo Luxemburgo, la franja horaria es otra. Siempre ha sido y será así.
El horario en el terminal es el de la ubicación del servidor, es decir, que si el broker está ubicado en Londres, pero el servidor está en por ejemplo Luxemburgo, la franja horaria es otra. Siempre ha sido y será así.
Muchas gracias, estoy verificando sí el trader es real, hoy verifique y los precios de los cfds reportados en las operaciones, teniendo en cuenta la diferencia horaria mencionada antes, si coinciden con los valores de gráficas del mercado de Londres que consulte hoy.
Envíeme por mensaje privado más información sobre ese broker y podre decirle si está regulado, etc. Aquí en el foro están prohibidas ese tipo de discusiones.