Estoy completamente perdido - página 4
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
La zona horaria para datetime (segundos después de 1970) se basa en UTC. Al igual que la hora de Unix. Es UnixTime - tiempo Unix de 64 bits.
datetime - datetime = long (segundos de duración)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(otra fecha)
Por favor, no alimentes al troll.
Cuando respondes, le das poder al troll. Cuando ignoras al troll, se muere de hambre por atención y finalmente muere.
Creo que has hecho una excelente contribución. Tus posts son concisos y bien enseñados y recibes muchos "gracias" por tus esfuerzos.
Sí, creo que has hecho todo lo posible por este tipo.
¿Cómo se especifica una fecha en GMT?
whoop olvidó mql4 utiliza un concepto de tiempo roto, . Concedo la q retórica :-) la zona horaria depende de donde vino. de ahí todos los problemas ya que hay múltiples fuentes broker, ordenador, backtesting blah blah
Temía que las reglas de promoción de tipos de datos funcionaran así. Bien, entonces
datetime - datetime = long (segundos de duración)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(otra fecha)
Pero si digo X=Y-Z, o (Y-Z)/60, o algo así, donde X ya está declarado como un long o un int, e Y y Z son datetimes, ¿es eso muy, muy malo? Y si es así, ¿el static_cast lo arreglaría todo?
Raptoruk, no es independiente de la zona horaria. Por supuesto que la diferencia entre las 2 pm y las 3 pm es de 3600 en cualquier zona horaria. Pero, ¿qué pasa si sé que el comercio se detiene a las 5 pm hora del este el viernes, pero no sé qué zona horaria es la hora 0 (la medianoche del 1 de enero de 1970)? Entonces tenemos un problema, ¿no? Así que el 1 de enero de 1970 fue un jueves. Si la hora 0 está en GMT, entonces la negociación se detiene a las 46 horas de ese día, o sea 165600 módulo 604800. En otras palabras, con 604800 segundos en una semana, uso la operación aritmética X%604800 para el resto al dividir por 604800, y el comercio se detiene en 165600. Sin embargo, si el corredor es de 2 zonas horarias al este de eso y su basura es timestamped con algo que es 7200 más alto, entonces el comercio se detiene cuando time%604800 es 172800, no 165600.
Parece que hay incertidumbre sobre los índices de tiempo declarados. Supongo que tengo que hacer que mi código calcule los tiempos modulo 604800 en los que la negociación comienza y se detiene después de todo, sólo para estar seguro. Estoy pensando en buscar a través de algo como iTime('USDJPY',60,X) y encontrar huecos de 48 horas. Puedo confiar en que iTime es la hora de "apertura", el COMIENZO de la hora, ¿verdad? En otras palabras, el comercio se detiene 1 hora después del último índice de tiempo antes de una brecha de 2 días, y se reanuda exactamente en el comienzo de la primera después de la brecha, y luego añadir múltiplos de 604800 simplemente cambia la semana. Aunque habría complicaciones añadidas, como qué pasa si en alguna semana falta la última hora, o falta la primera. Tal vez usar iTime('USDJPY',1,X) para que esté fuera por minutos como máximo.
Oh wow, un montón de postes establecidos tan rápido por que uno. Para que lo sepan los demás, supongo que raptoruk está bien después de todo, pero un montón de improperios no son bienvenidos, así que si no eres ydrol o raptoruk o alguien nuevo con algo nuevo que decir, deja de postear, no soy un troll porque no me importan tus estados emocionales de una manera u otra y si tienes algo más que lanzar, que sepas que cae en saco roto.
Temía que las reglas de promoción de tipos de datos funcionaran así. Bien, entonces
datetime - datetime = long (segundos de duración)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(otra fecha)
Pero si digo X=Y-Z, o (Y-Z)/60, o algo así, donde X ya está declarado como un long o un int, e Y y Z son fechas-tiempo, ¿es eso muy, muy malo? Y si es así, ¿el static_cast lo arreglaría todo?
Raptoruk, no es independiente de la zona horaria.
Pero, ¿qué pasa si sé que el comercio se detiene a las 5 pm hora del este el viernes, pero no sé qué zona horaria es la hora 0 (la medianoche del 1 de enero de 1970)? Entonces tenemos un problema, ¿no?
Temía que las reglas de promoción de tipos de datos funcionaran así. Bien, entonces
datetime - datetime = long (segundos de duración)
datetime +/- seconds(long) = datetime(another date)
datetime +/- seconds(int) = datetime(otra fecha)
Pero si digo X=Y-Z, o (Y-Z)/60, o algo así, donde X ya está declarado como un long o un int, e Y y Z son datetimes, ¿es eso muy, muy malo? Y si es así, ¿el static_cast lo arreglaría todo?
No se trata de "reglas de promoción", sino de ser sensato (espero). Por lo general, yo mismo haría los encasillamientos anteriores.
Si el resultado de mi cálculo sigue siendo un número de segundos desde el 1/1/1970 (independientemente de la zona horaria o de la falta de ella) entonces lo mantendría como datetime.
De lo contrario, cualquier otra cosa (una duración, minutos desde el 1/1/1970, lo que sea) probablemente la almacenaría como un long. (A veces un int, especialmente para duraciones típicas, etc.)
Dicho esto, estoy desconcertado de cómo los diseñadores de MQL4 llegaron a no obligar a UTC para todos los datetime, y obligar a todos los corredores de enviar datos UTC, y sólo tener el cliente interpretar en localtime, porque su enfoque actual complica innecesariamente todo aguas abajo.
Hace que el cálculo de la hora GMT, y las horas de apertura y cierre de la sesión durante el backtesting sea más difícil de lo que debería ser, si se quiere hacer correctamente para todas las fuentes de datos de ticks.
(Por ejemplo, Alpari tiene múltiples zonas horarias en sus datos históricos, por lo que hay que tener cuidado con las fuentes de datos cuando se hace backtesting)
PS Editado mi anterior falsie :)
ydrol, por el amor de todo lo sagrado o lo que sea, por favor, dime -si lo sabes- si static_cast se puede usar en mql4. ¿Es lo mismo que en C++? En esta página https://docs.mql4.com/basis/types/casting nunca se menciona esto, no lo encuentro en los foros, no lo encuentro en ningún sitio. Me estoy encontrando con situaciones en mi codificación constantemente, no sólo al convertir datetime en long, sino datetime en double, donde es inevitable, por lo que quiero hacerlo bien. En concreto, el programa averigua en qué parte de la semana se encuentra una muestra, y lo enfatiza en sus cálculos en consecuencia - pero el tiempo modulo el número de segundos en una semana sigue siendo una variable de tipo datetime y, a menos que pueda lanzarla como algo más, está atascada de esa manera. Pero necesito realizar una función matemática de la misma, y que al final sea un doble, ya ves. Si no lo sabes, no te preocupes, pero por favor, dime si lo sabes cómo debo encasillar correctamente las cosas en este tipo de situación.
raptoruk, "No... bueno, tal vez tú sí, yo no, así que no, no lo hacemos". No para mí, ni para ti, ni para nosotros, sino para la validez de tu afirmación anterior de que es independiente de la zona horaria. Porque no importa en qué zona horaria se encuentre su corredor, el comercio en la divisa no sigue el reloj de su corredor. Son las 5 pm del este los viernes y los domingos. 10 pm GMT. ¡Y qué pasa con el horario de verano/horario estándar! ¿Qué pasa con eso? Algunos países no añaden una hora o la restan, o lo hacen en un día diferente, por lo que podrías acabar con un código que tiene una hora de diferencia en algunas partes del año, si no hay una buena manera de hacerlo. Yo, no me he decidido por un corredor. El que estoy probando está en GMT+2 pero creo que ahora no me gustan, basándome en su cuenta demo. Y si pruebo uno de verdad, quizás quiera usar otro diferente. Así que no quiero que la zona horaria del broker esté codificada en el programa si es fácil no hacerlo. No vuelvas a ser como el otro tipo, que trata de convertir todo en una oportunidad para lanzar un insulto en lugar de tomar la pregunta al pie de la letra.