Cualquier pregunta de novato, para no saturar el foro. Profesionales, no pasen de largo. En ninguna parte sin ti - 6. - página 557
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
No tengo nada que objetar a los principios, pero el hombre quiere ejecutar el Asesor Experto en el probador, por lo que sus opciones no le convienen.
Utiliza mi variante, funcionará tanto en real como en el probador, pero hasta que no hayan hecho una función para contabilizar automáticamente el horario de verano, define la hora de transición para este año como
De marzo de 2013 a noviembre de 2014 funcionará y se probará correctamente. Ajuste el turno de acuerdo con su corredorNo voy a mirar donde está escrito que el tiempo se genera en el probador, tú mismo lo sabes. Pero en la ayuda se dice específicamente que
Mientras que no dice nada específico sobre StringToTime().
Lo único que hay que tener en cuenta es el tiempo en el probador (del servidor DC). Y en consecuencia, al hacer las pruebas debe tener un historial del mismo tipo de cuenta en el que funcionará este búho.
No voy a buscar dónde dice que se genera el tiempo en el probador, eso lo sabes tú mismo. Pero en la ayuda se dice específicamente que
Mientras que no dice nada específico sobre StringToTime().
Lo único que hay que tener en cuenta es el tiempo en el probador (del servidor DC). Por eso, al hacer las pruebas, hay que tener un historial del mismo tipo de cuenta en el que funcionarán estos búhos.
Alexey, no tengo ninguna pregunta sobre la función StrToTime() La pregunta es diferente. Volverá la hora correcta, pero las 21 horas de hoy son 22 horas antes del 9 de marzo. Por eso he escrito funciones que tienen en cuenta correctamente el DST del broker.
Sin ella, si un Asesor Experto funciona de acuerdo con algún horario es imposible de probar. Todo se desplaza una hora. No hay problemas en el comercio real, pero sí en el probador. Llevo mucho tiempo pidiendo a los desarrolladores que habiliten la función que calcula los desplazamientos de tiempo. Han implementado TimeGMT(), pero está ligado a la hora local y a la zona horaria del ordenador. Y tienes que tener un turno de frenado. Y su horario de verano es diferente al nuestro. Los corredores cambian el primer domingo de noviembre el segundo domingo de marzo y Rusia (si será...) el último domingo de octubre el último domingo de marzo. Así que por ahora tienes que escribir tus propias funciones.
No tengo ninguna objeción a los principios, pero el hombre quiere ejecutar el Asesor Experto en el probador, por lo que sus opciones no le convienen.
Utilice mi variante, funcionará tanto en real como en tester, pero hasta que no hicieron una función para tener en cuenta automáticamente el horario de verano, determinar el tiempo de transición a este año como
De marzo de 2013 a noviembre de 2014 funcionará y probará correctamente. Ajuste el turno de acuerdo con su corredorBien. Gracias. Le haré saber el resultado.
Es necesario comprobar en los gráficos < h4 la hora de la última barra del viernes actual y del viernes anterior al 8 de marzo. Si estas horas coinciden, entonces el valor de hrd es constante y no depende del cambio horario de invierno-verano y entonces todo es sencillo y funcionará correctamente durante las pruebas independientemente del cambio horario de invierno-verano
pero si estos dos tiempos son diferentes (difieren en 1 hora) entonces como escribí antes.
Deberíamos comprobar en el gráfico M1 el momento de la última barra del viernes actual y del viernes anterior al 8 de marzo. Si estas horas coinciden, entonces el valor de hrd es constante y no depende de la transición al horario de invierno-verano, y entonces todo es sencillo y funcionará correctamente durante las pruebas independientemente de la transición invierno-verano
pero si estos dos tiempos son diferentes (difieren en 1 hora) entonces como escribí antes.
¿Por qué hay un tiempo de 15 minutos en el código, es decir, quiere decir que 15 minutos antes del final de la sesión se inicia el reequilibrio de la cartera? Ciertamente he notado esos momentos en mt4 en fresch y he visto buenos niveles en algunos pares de divisas.
Por ejemplo, quiero cerrar las operaciones incluso 1 minuto antes del final de la sesión, porque cuando se deja una orden para el fin de semana, ocurre que el lunes el precio de apertura puede saltar 100, o 200, o incluso más pips.
Todavía no lo he probado. Lo haré más tarde hoy.
Pues esto no debería funcionar en el probador.
Las funciones se basan en la hora actual, y lo que he escrito arriba funcionará porque TimeCurrent() y TimeDayOfWeek() funcionan correctamente. Sólo hay que añadir la función para cambiar al horario de verano e invierno, es decir, el parámetro hrd. El cambio suele realizarse de acuerdo con la hora DST estadounidense (primer domingo de noviembre, segundo domingo de marzo), pero algunos corredores no realizan el cambio, por lo que debe utilizar su
Si mi broker está en Rusia y yo en Ucrania, entonces no hay cambio de horario de verano o de invierno, entonces resulta que no hay cambio de horario de verano en mi broker, sino sólo la hora local?
No es necesario comparar la hora del corredor y la suya local. Por mucho que mueva su reloj, la hora de finalización de la sesión del corredor en el gráfico no cambiará. La pregunta era sobre la transición a las cotizaciones en horario de verano de los corredores el 8 y 9 de marzo, y algunos corredores lo hacen y otros no.
Escribí - mira los gráficos para las últimas horas de barra antes y después del 9 de marzo, si son iguales entonces usa la última opción simple, si difieren por una hora entonces la más compleja.
Chicos, me quito el sombrero :) Tanto DayOfWeek() TimeDayOfWeek(datetimedate) como fórmulas similares funcionarán correctamente en el probador. El probador modela la hora del tick que procesa, por eso en DayOfWeek() que toma la última hora conocida del servidor también funciona. Por supuesto, es más correcto utilizar TimeDayOfWeek(dt1)
En general todo es correcto, lo único que falta es tener en cuenta el tiempo de transición de corredor a tiempo de invierno-verano, si lo hay, como escribí arriba.