Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Você está confuso com algo com mais de dez anos de idade? Você já ouviu falar do Y2K? Se não, você ficaria intrigado com a razão pela qual as datas eram armazenadas com apenas dois dígitos por ano, então depois de 1999 foi o ano de 1900 ou 19100.
Você provavelmente está intrigado porque os endereços IP estão limitados a 4,2 bilhões em um mundo de 7 bilhões de pessoas. Alguém tomou essa decisão na DARPA ao tentar conectar os (dezenas) computadores mainframe existentes no país. Agora estamos nos convertendo para IPv6 a partir do IPv4.
Supere você mesmo. Isto não é Berger King, você não entende do seu jeito. Alguém tomou uma decisão que parecia razoável na época e agora não é. Lide com isso.
ydrol, pelo amor de tudo o que é sagrado ou o que quer que seja, por favor me diga - se você sabe - se a transmissão_estática pode ser usada em mql4! É o mesmo que em C++? Esta página https://docs.mql4.com/basis/types/casting nunca menciona isto, não consigo encontrá-lo nos fóruns, não consigo encontrá-lo em lugar algum. Estou me deparando com situações em minha codificação constantemente, não apenas na hora de tornar a data longa, mas na hora de dobrar, onde é inevitável, então eu quero fazer isso corretamente. Nomeadamente o programa calcula em que parte da semana uma amostra está, e a enfatiza em seus cálculos de acordo - mas o módulo de tempo o número de segundos em uma semana ainda é uma variável do tipo data/hora e, a menos que eu possa lançá-la como outra coisa, ela está presa dessa forma. Mas preciso executar uma função matemática dela, e que seja um duplo no final, você vê. Se você não sabe, então não se preocupe, mas por favor me diga se você faz como eu devo datilografar corretamente as coisas neste tipo de situação.
Há uma seção inteira nos documentos sobre tipos de dados e digitação. Você pressiona F1 enquanto está usando o editor?
É o fuso horário do servidor do seu corretor. PERÍODO. Qualquer data que você receber do mt4 é o fuso horário de seu servidor. (Excluindo TimeLocal() e o novo mt5 TimeGMT)
Você está confuso com algo com mais de dez anos de idade? Você já ouviu falar do Y2K? Se não, você ficaria intrigado com a razão pela qual as datas eram armazenadas com apenas dois dígitos por ano, então depois de 1999 foi o ano de 1900 ou 19100.
Você provavelmente está intrigado porque os endereços IP são limitados a 4,2 bilhões em um mundo de 7 bilhões de pessoas. Alguém tomou essa decisão na DARPA ao tentar conectar os (dezenas) computadores mainframe existentes no país. Agora estamos nos convertendo para IPv6 a partir do IPv4.
Supere você mesmo. Isto não é Berger King, você não entende do seu jeito. Alguém tomou uma decisão que parecia razoável na época e agora não é. Lide com isso.
É o fuso horário do servidor do seu corretor. PERÍODO. Qualquer data que você receber do mt4 é o fuso horário de seu servidor. (Excluindo TimeLocal() e o novo mt5 TimeGMT.
Dragando isto novamente apenas porque estou atualmente migrando minhas funções TimeZone/Session para uma classe de mql4++ arrumada!
WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.
Estou lidando com isso, mas ainda estou intrigado porque tenho que fazê-lo em primeiro lugar! As melhores práticas de gerenciamento de informações de fuso horário existem há muito tempo. desde 1988. Por exemplo, para ISO 8601
Osfusos horários na ISO 8601 são representados como hora local (com o local não especificado), como UTC, ou como uma compensação do UTC.
Se nenhuma informação de relação UTC é dada com uma representação temporal, presume-se que a hora seja na hora local. Embora possa ser seguro assumir a hora local ao se comunicar no mesmo fuso horário, é ambíguo quando usado na comunicação através de diferentes fusos horários. [Minha ênfase] Normalmente é preferível indicar um fuso horário (designador de zona) usando a notação da norma".
O bit sublinhado é conhecido em TI há quase 30 anos, se não mais. O formato de data/hora MQL é derivado do UnixTime (eles não tiraram a data mágica 1/1/1970 da metade do ar), então eles deveriam estar cientes disso agora.
Novamente em 1988, o POSIX ratificou o UnixTime
"O comitê POSIX foi influenciado por argumentos contra a complexidade nas funções da biblioteca, e definiu firmemente o tempo Unix de maneira simples em termos dos elementos do tempo UTC. [Minha Ênfase]
Arquitetos de sistemas ou desenvolvedores que projetam sistemas cliente-servidor há 10 anos (o que nem há muito tempo), que trocam informações críticas de tempo, deveriam ter tido informações suficientes para antecipar/evitar a confusão do fuso horário atual. Comerciantes em um fuso horário, obtêm dados em outro fuso horário, que às vezes querem que seja interpretado em outro fuso horário (por exemplo, NY). As únicas desculpas são:
- ignorância
- baixa prioridade (a confusão da TZ beneficia os corretores e não os comerciantes?)
- alguma consideração técnica/constrição/requisito que não é óbvio para nós no exterior. Talvez desenhando gráficos ou algo assim? Embora não seja tão difícil adicionar/subtrair uma compensação conhecida?
Tudo isso me intriga, como eu disse antes. Sinto que não deveria precisar escrever código para calcular a hora GMT durante o backtesting! Mas TimeGMT() e TimeLocal() não são corretamente modelados, (ambos são definidos para a TZ não específica derivada de dados históricos), portanto, precisamos desempenhar nossas próprias funções de fuso horário, para calcular com precisão o UTC e assim os horários de início e fim de sessão durante o backtesting.
PS A ironia de ser dito pela WHRoeder para "superar a mim mesmo" não se perde :)