Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Yedelkin:
Mais ce faisant, je devrais accepter trois types de risques :
- le risque que les cotations arrivent en fait à une heure qui ne correspond pas au fuseau horaire GMT+1 ;
- le risque que l'heure indiquée dans les devis ne corresponde pas réellement à l'heure d'été ;
- le risque que le passage à l'heure d'hiver ne soit pas mis en œuvre pour une période de cotation autre que le 28 octobre.
C'est exactement ce dont je parle !
Très bien, cette discussion semble avoir atteint sa conclusion puisque la principale réponse de l'organisateur est que ce sera GMT+2 jusqu'au 28 octobre 2012 et GMT+1 après le 28 octobre.
La question des données historiques ne m'intéresse plus, car j'ai simplement tenu compte de ces changements dans l'EA.
J'ai essayé d'utiliser les fonctions sur les données historiques pour déterminer l'heure :
Tous montrent le même temps = TimeCurrent(); Ofset=0 ;
Pouvez-vous me dire, peut-être que je fais quelque chose de mal ?
Si je fais tout correctement, alors comment puis-je utiliser ces fonctions lors des tests ?
J'ai essayé d'utiliser les fonctions sur les données historiques pour déterminer l'heure :
Tous montrent le même temps = TimeCurrent() ; Ofset=0 ;
Pouvez-vous me dire si je fais quelque chose de mal ?
cher Roche... Je ne comprends pas pourquoi il est si difficile de répondre à la question de savoir s'il y aura un passage à l'heure d'hiver le 28 octobre ?
tout le monde ici n'est pas un super-programmeur capable de faire de la fusion nucléaire au moyen de µl !!!!. (la majeure partie de la langue se trouve de l'autre côté de l'écran).
c'est le forum pour demander !!!!!!!!!!! (s.m.)
mais comment faire un amendement ?
Oui, c'est exact. Voir l'article"Les bases du test dans MetaTrader 5", section "Simulation du temps dans le testeur". Tous affichent la même heure = TimeGMT().
Oui, merci, j'ai vu ça. C'est à peu près tout.
Ce n'est qu'une raison pour répéter le même conseil : dans les transactions orientées vers certains fuseaux horaires, vous devriez utiliser TimeGMT(). De cette façon, vous obtiendrez cette "universalité", qui a été mentionnée hier :)
Dans le commerce, oui, mais dans les tests ?
Comment puis-je savoir si l'heure d'été a été modifiée lors des essais ? Il s'avère que vous ne pouvez pas ?????.
Dans le commerce, oui, mais dans les tests ?
Comment puis-je savoir si l'heure d'été a été modifiée lors des essais ? Il s'avère qu'il n'y a aucun moyen d'accéder à ? ????.
Et dans les tests aussi. Jugez-en par vous-même. Si nous partons de l'heure GMT, nous devons supposer que ce fuseau horaire reste inchangé tout au long de l'année. Après tout, tous les autres fuseaux horaires, s'ils ont l'heure d'été, ajoutent une heure à l'heure GMT. Cela signifie que dans l'orientation tactique GMT, vous devez contrôler si le fuseau horaire souhaité est en heure d'été ou d'hiver. En d'autres termes, le code doit déjà contenir des contrôles pour l'apparition/la fin de l'heure d'été dans le fuseau horaire souhaité. Ces contrôles fonctionneront dans le testeur.
Bien sûr, c'est vrai si les citations dans l'historique sont stockées avec des heures GMT, mais cette question ne s'est pas encore posée :/.
mais comment faire un amendement ?