Londres Break-out

 

Prezados membros do fórum,

Desde algumas semanas estou tentando avançar com a MQL4, mas que desafio!! Eu já esperava ser um especialista! mas não sou e espero conseguir um pouco de ajuda.

Estou tentando construir um consultor especializado para a sessão de abertura em Londres. Quero que meu consultor especializado calcule o alto e o baixo dos 5 bares antes da abertura de Londres e depois calcule o alto e o baixo.

Para esta função assumo que tenho que usar o alto da função iHigh e o baixo da função iLow para calcular o intervalo. Mas esta faixa então estará mudando durante o dia. Quero que os altos e baixos desse intervalo sejam estáticos e não variáveis.

Alguém tem alguma idéia?

Obrigado de antemão!

 
Nour:

Prezados membros do fórum,

Desde algumas semanas estou tentando avançar com a MQL4, mas que desafio!! Eu já esperava ser um especialista! mas não sou e espero conseguir um pouco de ajuda.

Estou tentando construir um consultor especialista para a sessão de abertura em Londres. Quero que meu consultor especializado calcule o alto e o baixo dos 5 bares antes da abertura de Londres e depois calcule o alto e o baixo.

Para esta função assumo que tenho que usar o alto da função iHigh e o baixo da função iLow para calcular o intervalo. Mas esta faixa então estará mudando durante o dia. Quero que os altos e baixos desse intervalo sejam estáticos e não variáveis.

Alguém tem alguma idéia?

Obrigado de antemão!


como se encontra o bar onde começa a abertura de londres.

mostre como você o faz

 

Esse é outro problema deVries, não sei agora como encontrar o bar onde Londres abre...

Eu ainda sou muito novo na MQL4

 

... estou perdendo algo, ou as funções de data/hora incorporadas na MQL4 ainda são inadequadas para este tipo de coisa?

Duas questões:

* Você não pode obter com segurança o offset entre o servidor do corretor e o GMT porque (a) ele pode mudar com o horário de verão, e (b) qualquer comparação do TimeCurrent() com o TimeGMT() para calcular um offset falha nos fins de semana.

* Mesmo que você possa obter o offset atual enquanto o mercado estiver aberto, não há uma maneira integrada de traduzir o horário GMT para outro fuso horário, como Londres.

Em outras palavras: não há forma embutida de determinar (a) o servidor do corretor funciona no CET, e portanto (b) o horário de Londres para cada bar está 1 hora atrasado em relação ao horário reportado pelo MT4.

 

Nour:

Esse é outro problema deVries, não sei agora como encontrar o bar onde Londres abre...

Eu ainda sou muito novo na MQL4

https://docs.mql4.com/series/ibarshift
 
gchrmt4:

... estou perdendo algo, ou as funções de data/hora incorporadas na MQL4 ainda são inadequadas para este tipo de coisa?

Duas questões:

* Você não pode obter com segurança o offset entre o servidor do corretor e o GMT porque (a) ele pode mudar com o horário de verão, e (b) qualquer comparação do TimeCurrent() com o TimeGMT() para calcular um offset falha nos fins de semana.

* Mesmo que você possa obter o offset atual enquanto o mercado estiver aberto, não há uma maneira integrada de traduzir o horário GMT para outro fuso horário, como Londres.

Em outras palavras: não há forma embutida de determinar (a) o servidor do corretor funciona no CET, e portanto (b) o horário de Londres para cada bar está 1 hora atrasado em relação ao horário reportado pelo MT4.


Parece que o TimeGMT() não muda com o horário de verão. Por exemplo, eu moro nos Estados Unidos, portanto atualmente meu fuso horário local é EDT. O servidor MT4 do meu corretor é atualmente o EEST. Agora, considere o seguinte código e sua saída:

   Print ("1. GMT = ", TimeToString(TimeGMT()));
   Print ("2. Local Time (EDT) = ", TimeToString(TimeLocal()));
   Print ("3. Daylight Saving Adjustment: ", TimeDaylightSavings()/3600);
   Print ("4. GMTOffset for TimeLocal = ", TimeGMTOffset()/3600);
   Print ("5. Server Time (EEST) = ", TimeToString(TimeCurrent()));
   
   int local = (TimeLocal() - TimeGMT()) / 3600;
   int server = MathRound((TimeCurrent() - TimeGMT()) / 3600.0);
   string prt = "TimeLocal is ";
   if (local > 0)
      prt = StringConcatenate(prt, "GMT+", MathAbs(local));
   else if (local < 0)
      prt = StringConcatenate(prt, "GMT-", MathAbs(local));
   else
      prt = StringConcatenate(prt, "GMT");
      
   prt = StringConcatenate(prt, " and TimeCurrent is ");
   if (server > 0)
      prt = StringConcatenate(prt, "GMT+", MathAbs(server));
   else if (local < 0)
      prt = StringConcatenate(prt, "GMT-", MathAbs(server));
   else
      prt = StringConcatenate(prt, "GMT");
    
   Print (prt);

17:52:28 Expert TestEA-1 EURUSD,H1: carregado com sucesso

17:52:28 TestEA-1 EURUSD,H1: 1. GMT = 2014.03.11 21:52

17:52:28 TestEA-1 EURUSD,H1: 2. hora local (EDT) = 2014.03.11 17:52

17:52:28 TestEA-1 EURUSD,H1: 3. Ajuste da economia da luz do dia: -1

17:52:28 TestEA-1 EURUSD,H1: 4. GMTOffset para TimeLocal = 4

17:52:28 TestEA-1 EURUSD,H1: 5. horário do servidor (EEST) = 2014.03.12 00:52

17:52:28 TestEA-1 EURUSD,H1: HorárioLocal é GMT-4 e HorárioCorrente é GMT+3

Eu verifiquei o horário GMT acima com o de Londres, e eles eram os mesmos (Londres não muda para BST até o final de março). Portanto, acredito que o TimeGMT() retorna ao GMT sem adicionar o ajuste local do horário de verão. EDT é definido como UTC-4 e EEST é definido como UTC+3.

Além disso, se você precisar determinar quando o horário de verão começa e termina para os EUA ou para a UE, veja estas funções.

 
Thirteen:

Verifiquei o horário GMT acima com o de Londres [...]

Como você quase certamente sabe... uma das questões é que a compensação entre a hora do corretor e o GMT (a) pode ou não ser variável com base na economia diurna e (b) se é ou não variável não pode ser determinada com base nas informações que o MT4 fornece. Não analisei estas funções em nenhum detalhe, mas acho que concordamos que não é possível fazer tal cálculo com base apenas nas informações que a MT4 fornece.

Até onde posso ver, no início de abril o código acima começará a dizer que o corretor está no GMT+4. Meu ponto é que não há como saber pelo que o MT4 lhe diz que, na semana anterior, o corretor estava no GMT+3 e que os usos de, por exemplo, iBarShift() podem precisar ser ajustados de acordo se você quiser calcular a atividade de preços em horários GMT específicos, ou compensações de horários GMT.

BTW, se você executou o código acima hoje, então seu corretor quase certamente não pode estar no EEST. Eles devem estar na EET até 30 de março. Se eles estão atualmente no GMT+3, então eles estão usando algo diferente do EEST. (A página a que você ligou diz "Durante esta época do ano, os locais na EEST estão agora na EET").

 

gchrmt4:

. . .

BTW, se você executou o código acima hoje, então seu corretor quase certamente não pode estar no EEST. Eles devem estar na EET até 30 de março. Se eles estão atualmente no GMT+3, então eles estão usando algo diferente do EEST. (A página a que você ligou diz "Durante esta época do ano, os locais na EEST estão agora na EET").

Meu corretor muda o fuso horário em seu servidor MT4 de GMT+2 para GMT+3 para corresponder às 17h00 de Nova Iorque, e o faz ao mesmo tempo em que os EUA mudam para o horário de verão, o que aconteceu em 09 de março de 2014. Na Europa, o GMT+2 corresponde aproximadamente ao EET para a hora padrão, portanto o GMT+3 corresponde ao EEST para o horário de verão. Veja, por exemplo, os fusos horários europeus. Portanto, como você pode ver, não há dúvida de que eu executei o código hoje quando meu fuso horário local é EDT e o fuso horário do meu corretor corresponde ao EEST.

[1] Até onde posso ver, no início de abril o código acima vai começar a dizer que o corretor está em GMT+4.

[2] Meu ponto é que não há como saber pelo que o MT4 lhe diz que, na semana anterior, o corretor estava no GMT+3 e que os usos de, por exemplo, iBarShift() podem precisar ser ajustados de acordo se você quiser calcular a atividade de preços em horários específicos GMT, ou compensações de horários GMT.

1. Por que ele retornaria o GMT+4 em abril? O horário do meu computador local já está ajustado para o horário de verão, e meu corretor já ajustou seu servidor para refletir o horário de verão, então o que mudará em abril?

2. Um corretor pode mudar seu horário para refletir o horário de verão, o que mudaria sua compensação para GMT. Mas você pode prever essa mudança. Por exemplo, enquanto as datas/horas em que o horário de verão começa e termina muda de ano para ano, essa mudança é previsível - e, portanto, programável. Basta codificar a regra. Mas o TimeGMT() deve retornar GMT independentemente do fuso horário local, fuso horário do corretor ou compensação do horário de verão.

Como você quase certamente sabe... uma das questões é que a compensação entre o horário do corretor e o GMT (a) pode ou não ser variável com base no horário de verão e (b) se é ou não variável não pode ser determinada com base nas informações que o MT4 fornece. Não analisei estas funções em nenhum detalhe, mas acho que concordamos que não é possível fazer tal cálculo com base apenas nas informações que a MT4 fornece.

Se um corretor se ajustar para o horário de verão, então esse ajuste mudaria seu offset para GMT, mas como eu disse acima, você pode prever essas mudanças e ajustar para elas. Ou se um lugar (por exemplo, Londres) se ajusta ao horário de verão, você pode codificar a regra local e assim prever essa mudança e se ajustar a ela.

 
Thirteen:

Se um corretor se ajusta ao horário de verão, então esse ajuste mudaria sua compensação para GMT, mas como afirmei acima, é possível prever essas mudanças e ajustar para elas. Ou se um lugar (por exemplo, Londres) se ajusta ao horário de verão, você pode codificar a regra local e assim prever essa mudança e ajustar-se a ela.

Ainda estou concordando fundamentalmente com você que as mudanças são previsíveis e codificáveis... mas não apenas utilizando as informações que o próprio MT4 fornece. Você tem que "codificar a regra local" para Londres GMT, em vez de dizer ao MT4 "me dê o tempo equivalente para x em Londres".

O horário de seu servidor GMT+3 pode corresponder ao EEST no sentido de que EEST é GMT+3 mas, de acordo com a Wikipedia e o worldclock.com, ainda não deveria estar em nenhum lugar no EEST. Essa mudança não deve acontecer até 30 de março. A hora atual em Chipre, Grécia, Israel, etc. é GMT+2.

Portanto, o que você provavelmente tem é um corretor rodando seus servidores no GMT+2, mas mudando para as datas americanas em vez das datas européias. Isso não é o mesmo que EET/EEST. (E é ainda menos previsível em termos de ser capaz de escrever código que ajusta automaticamente as horas e datas sem ter que pedir ao usuário algum tipo de entrada sobre que configurações de horário o corretor usa).

Se, portanto, o corretor mudou recentemente de GMT+2 para GMT+3, em vez de estar prestes a mudar de GMT+3 para GMT+4, o que significa que a compensação atual entre o horário do corretor e o GMT estaria errada se você tentasse aplicá-la nas barras na semana passada, antes da mudança do relógio dos EUA. Esta semana, os bares do corretor estão 3 horas à frente de Londres. Na semana passada, eles estavam 2 horas à frente. (E, a partir de 30 de março, eles estarão novamente 2 horas à frente.) Se você pegar esse offset atual de 3 horas e usá-lo para tentar obter o preço às 8 horas da manhã de Londres em um dia da semana passada, você terá a resposta errada.

Tudo o que estou dizendo é que a informação que é possível obter apenas do próprio MT4 - compensação atual entre o horário do corretor e o GMT - é inadequada na prática para se fazer coisas como dizer "trabalhar o preço de abertura em Londres na última quarta-feira".

 

Como o MT4 poderia ser mais adequado para fazer isso? Eu não sei quanto a você, mas com certeza não gostaria da tarefa de criar uma calculadora regional de compensação histórica GMT. Você pode simplesmente imaginar ? omg. Se eu fizer isso, vou colocá-la no mercado, é melhor que todos vocês tenham um grande e gordo livro de cheques ;)

Estou apenas brincando, não há como tentar codificar isso. Mas, aposto que ele já o fez.

Razão: