Estoy completamente perdido - página 5
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
¿Te desconcierta algo de hace más de diez años? ¿Has oído hablar del efecto 2000? Si no es así, estarías perplejo por qué las fechas se almacenaban con sólo dos dígitos por año, de modo que después de 1999 era el año 1900 o 19100.
Probablemente te intriga por qué las direcciones IP están limitadas a 4,2 mil millones en un mundo de 7 mil millones de personas. Alguien tomó esa decisión en DARPA cuando intentaba conectar las (docenas) de ordenadores centrales existentes en el país. Ahora estamos convirtiendo a IPv6 desde IPv4.
Supéralo. Esto no es Berger King, no lo consigues a tu manera. Alguien tomó una decisión que parecía razonable en su momento y ahora no lo es. Asúmelo.
¡ydrol, por el amor de todo lo que es sagrado o lo que sea, por favor dime - si lo sabes - si static_cast se puede utilizar 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.
Hay toda una sección en los documentos sobre los tipos de datos y el encasillamiento.
Es la zona horaria del servidor de tu broker. PERIODO. Cualquier fecha que obtengas de mt4 es la zona horaria de tu servidor. (Excluyendo TimeLocal() y el nuevo mt5 TimeGMT)
¿Te desconcierta algo de hace más de diez años? ¿Has oído hablar del efecto 2000? Si no es así, estarías desconcertado por qué las fechas se almacenan con sólo dos dígitos por año, de modo que después de 1999 era el año 1900 o 19100.
Probablemente te intriga por qué las direcciones IP están limitadas a 4.200 millones en un mundo de 7.000 millones de personas. Alguien tomó esa decisión en DARPA al intentar conectar las (docenas) de ordenadores centrales existentes en el país. Ahora estamos convirtiendo a IPv6 desde IPv4.
Supéralo. Esto no es Berger King, no lo consigues a tu manera. Alguien tomó una decisión que parecía razonable en su momento y ahora no lo es. Asúmelo.
Es la zona horaria del servidor de su broker. PERIODO. Cualquier fecha que obtenga de mt4 es la zona horaria de su servidor. (Excluyendo TimeLocal() y el nuevo mt5 TimeGMT.
¡Desenterrando esto de nuevo sólo porque actualmente estoy migrando mis funciones TimeZone/Session a una clase ordenada de mql4++!
WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.
Me estoy ocupando de ello, pero todavía estoy desconcertado por qué tengo que hacerlo en primer lugar. Las mejores prácticas en torno a la gestión de la información sobre la zona horaria existen desde hace mucho tiempo, desde 1988. Por ejemplo, para la norma ISO 8601
Laszonas horarias en ISO 8601 se representan como hora local (sin especificar la ubicación), como UTC, o como un desplazamiento de UTC.
Si no se da información sobre la relación UTC con una representación de la hora, se asume que la hora está en hora local. Mientras que puede ser seguro asumir la hora local cuando se comunica en la misma zona horaria, es ambiguo cuando se utiliza en la comunicación a través de diferentes zonas horarias[Énfasis mío] Normalmente es preferible indicar una zona horaria (designador de zona) utilizando la notación del estándar".
La parte subrayada se conoce en informática desde hace casi 30 años, si no más. El formato de fecha y hora de MQL se deriva de UnixTime (no sacaron la fecha mágica del 1/1/1970 de la nada), así que ya deberían ser conscientes de ello.
De nuevo en 1988, POSIX ratificó UnixTime
"El comité de POSIX se dejó llevar por los argumentos contra la complejidad de las funciones de la biblioteca y definió firmemente la hora de Unix de manera simple en términos de los elementos de la hora UTC. [Énfasis mío]
Los arquitectos de sistemas o los desarrolladores que diseñaban sistemas cliente-servidor hace 10 años (que no es tanto), que intercambian información crítica sobre la hora, deberían haber tenido suficiente información para anticipar/evitar el actual lío de zonas horarias. Los operadores de una zona horaria reciben datos en otra zona horaria, que a veces quieren que se interpreten en otra zona horaria (por ejemplo, en Nueva York). Las únicas excusas son
- la ignorancia
- baja prioridad (la confusión de la zona horaria beneficia a los corredores, no a los operadores).
- alguna consideración/restricción/requisito técnico que no es obvio para nosotros en el exterior. ¿Tal vez dibujar gráficos o algo así? Aunque no es tan difícil añadir/restar un desplazamiento conocido?
Todo lo anterior me desconcierta como he dicho antes. ¡Siento que no debería necesitar escribir código para calcular la hora GMT durante el backtesting! Pero TimeGMT() y TimeLocal() no están correctamente modelados, (ambos están ajustados a la TZ no específica derivada de los datos históricos) por lo que necesitamos rolear nuestras propias funciones de zona horaria, para calcular con precisión la UTC y por lo tanto las horas de inicio y fin de Sesión durante el backtesting.
P.D. La ironía de que WHRoeder me diga que "me supere" no se pierde :)