Sortie à Londres

 

Chers membres du forum,

Depuis quelques semaines, j'essaie d'avancer avec MQL4, mais quel défi ! J'espérais être déjà un expert, mais je ne le suis pas et j'espère avoir un peu d'aide.

J'essaie de construire un conseiller expert pour la séance d'ouverture de Londres. Je veux que mon conseiller expert calcule le haut et le bas des 5 barres avant l'ouverture de Londres et calcule ensuite le haut et le bas.

Pour cette fonction, je suppose que je dois utiliser le haut de la fonction iHigh et le bas de la fonction iLow pour calculer la fourchette. Mais cette fourchette va changer au cours de la journée. Je veux que le haut et le bas de cette plage soient statiques et non variables.

Quelqu'un a-t-il une idée ?

Merci à l'avance !

 
Nour:

Chers membres du forum,

Depuis quelques semaines, j'essaie de progresser avec MQL4, mais quel défi ! J'espérais être déjà un expert, mais je ne le suis pas et j'espère avoir un peu d'aide.

J'essaie de construire un conseiller expert pour la séance d'ouverture de Londres. Je veux que mon conseiller expert calcule le haut et le bas des 5 barres avant l'ouverture de Londres et calcule ensuite le haut et le bas.

Pour cette fonction, je suppose que je dois utiliser le haut de la fonction iHigh et le bas de la fonction iLow pour calculer la fourchette. Mais cette fourchette va changer au cours de la journée. Je veux que le haut et le bas de cette plage soient statiques et non variables.

Quelqu'un a-t-il une idée ?

Merci à l'avance !


comment trouver le bar où commence l'ouverture de Londres...

montrez comment vous faites

 

C'est un autre problème deVries, je ne sais pas comment trouver le bar où Londres ouvre...

Je suis encore assez nouveau dans MQL4

 

... est-ce que je rate quelque chose, ou est-ce que les fonctions date/heure intégrées à MQL4 sont toujours inadéquates pour ce genre de choses ?

Deux problèmes :

* Vous ne pouvez pas obtenir de manière fiable le décalage entre le serveur du courtier et l'heure GMT car (a) il peut changer avec l'heure d'été, et (b) toute comparaison de TimeCurrent() avec TimeGMT() pour calculer un décalage échoue pendant les week-ends.

* Même si vous pouvez obtenir le décalage actuel lorsque le marché est ouvert, il n'existe aucun moyen intégré de convertir l'heure GMT en un autre fuseau horaire tel que Londres.

En d'autres termes, il n'existe aucun moyen intégré de déterminer (a) que le serveur du courtier fonctionne à l'heure d'Europe centrale, et donc (b) que les heures de Londres pour chaque barre sont en retard d'une heure par rapport à l'heure indiquée par MT4.

 

Nour:

C'est un autre problème deVries, je ne sais pas comment trouver le bar où Londres ouvre...

Je suis encore assez nouveau dans MQL4

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

... est-ce que je rate quelque chose, ou est-ce que les fonctions date/heure intégrées à MQL4 sont encore inadéquates pour ce genre de choses ?

Deux problèmes :

* Vous ne pouvez pas obtenir de manière fiable le décalage entre le serveur du courtier et l'heure GMT car (a) il peut changer avec l'heure d'été, et (b) toute comparaison de TimeCurrent() avec TimeGMT() pour calculer un décalage échoue pendant les week-ends.

* Même si vous pouvez obtenir le décalage actuel lorsque le marché est ouvert, il n'existe aucun moyen intégré de convertir l'heure GMT en un autre fuseau horaire tel que Londres.

En d'autres termes, il n'existe aucun moyen intégré de déterminer (a) que le serveur du courtier fonctionne à l'heure d'Europe centrale, et donc (b) que les heures de Londres pour chaque barre sont en retard d'une heure par rapport à l'heure indiquée par MT4.


Il semble que TimeGMT() ne change pas avec l'heure d'été. Par exemple, je vis aux États-Unis, et mon fuseau horaire local est actuellement EDT. Le serveur MT4 de mon courtier est actuellement EEST. Maintenant, considérez le code suivant et son résultat :

   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 : chargé avec succès

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

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

17:52:28 TestEA-1 EURUSD,H1 : 3. ajustement de l'heure d'été : -1

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

17:52:28 TestEA-1 EURUSD,H1 : 5. heure du serveur (EEST) = 2014.03.12 00:52

17:52:28 TestEA-1 EURUSD,H1 : TimeLocal est GMT-4 et TimeCurrent est GMT+3

J'ai vérifié l'heure GMT ci-dessus avec celle de Londres, et elles étaient les mêmes (Londres ne passe pas en BST avant la fin du mois de mars). Je pense donc que TimeGMT() renvoie l'heure GMT sans ajouter l'ajustement local de l'heure d'été. EDT est défini comme UTC-4 et EEST est défini comme UTC+3.

En outre, si vous avez besoin de déterminer quand l'heure d'été commence et se termine aux États-Unis ou dans l'Union européenne, consultez ces fonctions.

 
Thirteen:

J'ai vérifié l'heure GMT ci-dessus avec celle de Londres [...]

Comme vous le savez certainement... l'un des problèmes est que le décalage entre l'heure du courtier et l'heure GMT (a) peut ou non être variable en fonction de l'heure d'été et (b) s'il est variable ou non, il ne peut pas être déterminé sur la base des informations que MT4 fournit. Je n'ai pas examiné ces fonctions en détail, mais je pense que nous sommes d'accord sur le fait que vous ne pouvez pas effectuer un tel calcul sur la seule base des informations fournies par MT4.

Pour autant que je puisse voir, au début du mois d'avril, le code ci-dessus commencera à dire que le courtier est à GMT+4. Ce que je veux dire, c'est qu'il n'y a aucun moyen de savoir, à partir de ce que MT4 vous dit, qu'au cours de la semaine précédente, le courtier était à GMT+3 et que les utilisations de iBarShift(), par exemple, doivent être ajustées en conséquence si vous voulez calculer l'activité des prix à des heures GMT spécifiques ou à des décalages d'heures GMT.

BTW, si vous avez exécuté le code ci-dessus aujourd'hui, votre courtier ne peut certainement pas être sur EEST. Il devrait être en EET jusqu'au 30 mars. S'il est actuellement à GMT+3, il utilise autre chose que EEST. (La page dont vous avez donné le lien indique que "Pendant cette période de l'année, les sites sur EEST sont maintenant sur EET").

 

gchrmt4:

. . .

BTW, si vous avez exécuté le code ci-dessus aujourd'hui, il est presque certain que votre courtier ne peut pas être sur EEST. Il devrait être sur EET jusqu'au 30 mars. S'il est actuellement à GMT+3, il utilise autre chose que EEST. (La page dont vous avez donné le lien indique que "pendant cette période de l'année, les sites sur EEST sont maintenant sur EET").

Mon courtier change le fuseau horaire sur son serveur MT4 de GMT+2 à GMT+3 pour correspondre à la fermeture de New York à 17h, et il le fait en même temps que les États-Unis passent à l'heure d'été, ce qui est arrivé le 09 mars 2014. En Europe, GMT+2 correspond approximativement à EET pour l'heure normale, et GMT+3 correspond à EEST pour l'heure d'été. Voir, par exemple, les fuseaux horaires européens. Ainsi, comme vous pouvez le constater, il ne fait aucun doute que j'ai exécuté le code aujourd'hui alors que mon fuseau horaire local est EDT et que le fuseau horaire de mon courtier correspond à EEST.

[1] D'après ce que je peux voir, au début du mois d'avril, le code ci-dessus commencera à dire que le courtier est à GMT+4.

[2] Ce que je veux dire, c'est qu'il n'y a aucun moyen de savoir, à partir de ce que MT4 vous dit, qu'au cours de la semaine précédente, le courtier était à GMT+3 et que les utilisations de iBarShift(), par exemple, doivent être ajustées en conséquence si vous voulez connaître l'activité des prix à des heures GMT spécifiques ou à des décalages des heures GMT.

1. Pourquoi retournerait-il l'heure GMT+4 en avril ? L'heure de mon ordinateur local est déjà ajustée pour l'heure d'été, et mon courtier a déjà ajusté son serveur pour refléter l'heure d'été, alors qu'est-ce qui va changer en avril ?

2. Un courtier peut changer son heure pour refléter l'heure d'été, ce qui modifierait son décalage par rapport à l'heure GMT. Mais vous pouvez prévoir ce changement. Par exemple, si les dates/heures de début et de fin de l'heure d'été changent d'une année sur l'autre, ce changement est prévisible - et donc programmable. Il suffit de coder la règle. Mais TimeGMT() doit retourner l'heure GMT indépendamment du fuseau horaire local, du fuseau horaire du courtier ou du décalage de l'heure d'été.

Comme vous le savez certainement... l'un des problèmes est que le décalage entre l'heure du courtier et l'heure GMT (a) peut ou non être variable en fonction de l'heure d'été et (b) s'il est variable ou non ne peut être déterminé sur la base des informations fournies par MT4. Je n'ai pas examiné ces fonctions en détail, mais je pense que nous sommes d'accord sur le fait que vous ne pouvez pas effectuer un tel calcul sur la seule base des informations fournies par MT4.

Si un courtier s'adapte à l'heure d'été, cet ajustement modifiera son décalage par rapport à l'heure GMT, mais comme je l'ai dit plus haut, vous pouvez prévoir ces changements et vous y adapter. Ou si un lieu (par exemple, Londres) ajuste l'heure d'été, vous pouvez coder la règle locale et ainsi prévoir ce changement et l'ajuster.

 
Thirteen:

Si un courtier s'adapte à l'heure d'été, cet ajustement modifiera son décalage par rapport à l'heure GMT, mais comme je l'ai dit plus haut, vous pouvez prévoir ces changements et vous y adapter. Ou si un lieu (par exemple, Londres) ajuste l'heure d'été, vous pouvez coder la règle locale et ainsi prédire ce changement et l'ajuster.

Je suis toujours fondamentalement d'accord avec vous sur le fait que les changements sont prévisibles et codifiables... mais pas uniquement en utilisant les informations que MT4 lui-même fournit. Vous devez "coder la règle locale" pour l'heure GMT de Londres, plutôt que de dire à MT4 "donnez-moi l'heure équivalente de x à Londres".

L'heure de votre serveur de GMT+3 peut correspondre à l'EEST dans le sens où l'EEST est GMT+3 mais, selon Wikipedia et worldclock.com, nulle part ne devrait encore être à l'EEST. Ce changement ne devrait pas avoir lieu avant le 30 mars. L'heure actuelle à Chypre, en Grèce, en Israël, etc. est GMT+2.

Par conséquent, ce que vous avez probablement, c'est un courtier qui fait fonctionner ses serveurs à GMT+2, mais qui passe à l'heure d'été aux dates américaines plutôt qu'aux dates européennes. Ce n'est pas la même chose que EET/EEST. (Et c'est encore moins prévisible en termes de capacité à écrire un code qui ajuste automatiquement les heures et les dates sans avoir à demander à l'utilisateur une sorte d'entrée sur les paramètres horaires utilisés par le courtier).

Si, par conséquent, le courtier est récemment passé de GMT+2 à GMT+3, plutôt que d'être sur le point de passer de GMT+3 à GMT+4, cela signifie que le décalage actuel entre l'heure du courtier et l'heure GMT serait erroné si vous essayiez de l'appliquer aux barres de la semaine dernière, avant le changement d'heure aux États-Unis. Cette semaine, les barres du courtier ont 3 heures d'avance sur Londres. La semaine dernière, elles avaient 2 heures d'avance. (Et, à partir du 30 mars, elles auront à nouveau 2 heures d'avance.) Si vous prenez ce décalage actuel de 3 heures et que vous l'utilisez pour essayer d'obtenir le prix à 8 heures du matin, heure de Londres, un jour de la semaine dernière, vous obtiendrez une mauvaise réponse.

Tout ce que je veux dire, c'est que les informations qu'il est possible d'obtenir à partir du MT4 lui-même - le décalage actuel entre l'heure du courtier et l'heure GMT - sont inadéquates en pratique pour faire des choses comme "calculer le prix d'ouverture à Londres mercredi dernier".

 

Comment MT4 pourrait-il être plus adapté à cette tâche ? Je ne sais pas pour vous, mais je ne me réjouirais pas de la création d'un calculateur de décalage GMT historique régional. Pouvez-vous imaginer ? omg. Si jamais je le fais, je le mettrai sur le marché, vous avez intérêt à avoir un gros carnet de chèques ;)

Je plaisante, il n'y a aucune chance que j'essaie de coder ça. WHR pourrait le faire, je parie qu'il l'a déjà fait.

Raison: