tiempo en la terminal en los campeonatos - página 5

[Yedelkin]

sergeev:

Yedelkin:
Por favor, muestre cómo exactamente "dos líneas de código" responden a la pregunta planteada anteriormente, es decir, si se utiliza el horario de verano para la zona horaria a la que se refiere la hora de negociación del servidor (hora de cotización).

TimeTradeServer

La respuesta me parece errónea, por desgracia. La función no indica el uso del horario de verano para la zona horaria a la que se refiere la hora de negociación del servidor(hora de cotización). En otras palabras, aunque el servidor esté referenciado a la zona horaria GMT+1, la función TimeTradeServer no puede determinar si el servidor cambiará a GMT+2 en primavera. En otoño, volverá a cambiar en consecuencia.

En verano, esta función tampoco responde a la pregunta de si el servidor utiliza el horario de "verano" para las citas.

[Vladimir Gomonov]

Yedelkin:

La respuesta me parece errónea, por desgracia. La función no indica el uso del horario de verano para la zona horaria a la que se refiere la hora de negociación del servidor(hora de cotización). En otras palabras, aunque el servidor esté referenciado a la zona horaria GMT+1, la función TimeTradeServer no puede determinar si el servidor cambiará a GMT+2 en primavera. En otoño, volverá a cambiar en consecuencia.

En verano, esta función tampoco responde a la pregunta de si el servidor utiliza el horario de "verano" para procesar las cotizaciones.

No necesitas la hora del servidor.

Si el comercio se basa en el tiempo debido al ciclo global de los precios, entonces yo operaría estrictamente por GMT y no me preocuparía.

El tiempo del servidor es un factor de confusión innecesario para el cerebro (¡y el programa!).

[Павел Смирнов]

Estimados interlocutores.

Te falta el meollo de la cuestión aquí está mi cita:

Aquí hay una comparación de las cotizaciones del servidor de Alpari y Metaquotes:

partido -> 02.05.2011 -> turno -> 31.10.2011 -> partido -> 07.11.2011 -> turno

Hasta el 2.05.2011 las cotizaciones coinciden totalmente (al menos desde 2005). Luego se observa un cambio el 31.10.2011, pasando de nuevo a coincidir totalmente las cotizaciones hasta el 07.11.2011, allí de nuevo un cambio de una hora, y hasta la actualidad.

¡¡¡¡Estas "metamorfosis" no se pueden explicar de ninguna manera!!!! Si un comerciante dice que la hora de las cotizaciones EET es con el horario de verano, significa que la hora de las cotizaciones GMT+2 es desde el último domingo de octubre hasta el último domingo de marzo. Todas las demás horas son GMT+3 (horario de verano). Y no necesito comprobar nada en el código: ¡se toma como un axioma! Siempre sé a qué hora son las cotizaciones. En este caso no hay explicación lógica para tales desplazamientos. ¡Es un error en la historia de las cotizaciones! Tal vez ya se haya discutido, pero me he perdido este punto, pero es importante que en el futuro sea como debe ser.

Si la universalidad de los EAs es importante para ti, es decir, quieres que tu EA funcione correctamente sin importar los periodos de tiempo en que se encuentren ciertas cotizaciones, entonces creo que todas las herramientas están disponibles en MQL5 (no las he probado yo mismo, pero creo que el desarrollador).

No me importa esta universalidad. Dado que mi EA fue optimizado y desarrollado sobre las cotizaciones de Alpari, necesito saber cómo se comportarán las cotizaciones del servidor del Campeonato en comparación con las de Alpari para ajustar los parámetros del EA en consecuencia. ¡¡¡Necesito algo de certeza!!! El rendimiento de mi EA depende de ello.

Stringo respondió que la hora del servidor será GMT+1 con un cambio de horario de invierno. Esta hora se llama CET y ahora es GMT+2 (con el cambio de verano), el 28 de octubre de 2012 se pasará a la hora estándar (horario de invierno) y la hora será CET=GMT+1. Para mí es importante que los organizadores del Campeonato me confirmen lo que pienso. La frase "Sí, será" es suficiente.

Gracias.

[Yedelkin]

autoforex:

Estimados interlocutores. Te estás perdiendo el meollo de la cuestión...

A nadie le falta nada. A menudo sucede en este foro que una sola pregunta suscita un montón de otras. Y la esencia de la primera pregunta sigue siendo relevante sólo para el autor. Puedes verlo tú mismo.

autoforex:

Stringo respondió que la hora del servidor será GMT+1 con la transición al horario de invierno.

No era Stringo (hasta el punto de estar atento al seguir el hilo), pero eso es trivial. Tus últimas preguntas van dirigidas directamente a los organizadores, así que el resto no tiene nada que hacer en la discusión del "meollo del asunto". Por supuesto, todo el mundo desea buena suerte para conseguir la respuesta correcta en la forma adecuada.

...¡Quería agradecerle su persistencia en impulsar el tema! Muchos, después de una o dos consultas sin respuesta, simplemente abandonan el tema planteado :)

[Mario]

y sin embargo... ¿debe establecerse la modificación de la hora del 28 de octubre?

[Yedelkin]

maryan.dirtyn:

y sin embargo... ¿debe establecerse la modificación de la hora del 28 de octubre?

Depende de la lógica de la estrategia comercial. Por ejemplo, mi estrategia se basa en GMT, por eso tengo que corregirla de todas formas :). Si operara sólo en relación con la zona horaria CET, no me molestaría, como se ha descrito anteriormente.

[Mario]

El puesto se abre a las 9 de la mañana y se cierra a las 10 de la noche.

MqlDateTime time;
TimeCurrent(time);
if(DayClose && time.hour>=22){CLOSEALL(SY[i]); return;} 

las señales están bloqueadas en algunas noticias.

MqlDateTime time;
TimeCurrent(time);
if(time.mon==10 && time.day==4  && time.hour==14 && (time.min>15 && time.min<45)) News=true;

esta es la lógica.

¿después del 28 de octubre hay que añadir una hora?

[Rashid Umarov]

autoforex:
Por lo tanto, las cotizaciones del servidor del campeonato se desplazarán 1 hora con respecto a las cotizaciones de Alpari durante todo el campeonato (ya que utilizan la hora EET = GMT+2 y tienen el horario de verano).

¡¡¡Pido a los organizadores que confirmen la corrección de mis conclusiones!!!

Garantías sólo en sberbank. También puede pedir una dirección estimada de la tendencia y una garantía de que no cambiará durante el campeonato.

[Yedelkin]

maryan.dirtyn:

la posición se abre a las 9 de la mañana y se cierra a las 10 de la noche. en algunas noticias, las señales se bloquean. esa es la lógica. después del 28 de octubre, ¿hay que añadir una hora?

La lógica de su estrategia de negociación está ligada a la hora del servidor (hora del servidor de negociación). Desde que se anunció recientemente que para el campeonato se utilizará

MetaQuotes:

GMT+1 timezone
Con soporte de horario de verano.

Yo personalmente no me molestaría en tener en cuenta la corrección horaria, y no añadiría ni restaría nada "después del día 28". Pero tendría que asumir tres tipos de riesgo:

- El riesgo de que, de hecho, las cotizaciones lleguen con una hora que no corresponde a la zona horaria GMT+1;

- el riesgo de que la hora citada no admita de hecho el horario de verano;

- el riesgo de que no se aplique el cambio al horario de invierno para la fecha citada es el 28 de octubre.

Los riesgos son, por supuesto, mínimos, pero es aconsejable tenerlos en cuenta. Evitar estos riesgos es posible mediante la vinculación con el GMT:

MqlDateTime time;
TimeGMT(time);
//Плюс поправка на летнее время, если торговая деятельность завязана на таймзону с наличием летнего времени

[Павел Смирнов]

Rosh:
Garantías sólo en sberbank. Pida una dirección estimada de la tendencia y una garantía de que no cambiará durante el campeonato.

No sé qué ha provocado ese "sarcasmo" sobre mis preguntas, pero ¡hay cero información útil en tu respuesta!