Estou completamente perdido - página 5

 
Eu não sei o que você quer dizer com elenco estático. A questão do fuso horário é uma dor em mql. Com o antigo mql4, a abordagem era ter uma variável global que o usuário definia para os corretores compensar, você também pode obter tempo gmt usando a nova função timegmt, mas eu vi alguns relatórios que isto é buggy. Também não tenho certeza de como ele se comporta durante o backtesting. Tudo isso é uma bagunça, infelizmente. Mas não impossível de codificar por aí.
 
RaptorUK: OK, que fuso horário é uma data de 0 ?
É 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)
ydrol: Estou intrigado como os designers da MQL4 chegaram a não exigir a UTC para todas as datas,

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.

 
zortharg:

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?

 
WHRoeder:
É 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.

não, você se supera. Sério, fico intrigado porque essa decisão foi tomada quando foi projetada. E estou perfeitamente no meu direito de dizer isso. Liberdade de expressão e tudo isso. Você não tem o direito de tentar me reprimir mais do que eu a você. É baseado em um formato de tempo estabelecido que já usava utc por uma razão, e é muito mais antigo que 10 anos, e agora o mql4 tem problemas de fuso horário por causa de uma decisão que francamente me intriga. E estou autorizado a dizer isto. Você pode ser brincalhão com y2k o quanto quiser, isso não faz diferença. Trabalho na integração de sistemas há quase vinte anos e parece uma má decisão de projeto não consertá-la. Desculpe se você não consegue lidar com outra pessoa expressando sua opinião.
 
WHRoeder:
É 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.
e GlobalVariableSet() que é o tempo gmt derivado do relógio pc (não modelado)
 

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 :)