temps dans le terminal aux championnats - page 2
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
J'aimerais entendre un commentaire de la part des organisateurs du championnat.
Merci.
...ce n'est pas la seule question à laquelle nous n'obtiendrons pas de réponse - c'est la politique ... c'est celui qui paie le joueur de cornemuse qui décide de la musique.
Je me demande comment la réponse à la réponse "le serveur passera à l'heure d'hiver" ou "le serveur ne passera pas à l'heure d'hiver" en dépendra ?
Je suis simplement curieux de connaître la mise en œuvre logicielle associée à ces connaissances.
Avec prise en charge de l'heure d'été.
Quel est l'intérêt de cacher des informations sur l'heure du serveur du championnat et la présence/absence de l'heure d'été ?
Par exemple, le serveur du championnat n'est pas encore opérationnel.
Quel est le problème de définir soi-même l'heure d'été? Toutes les fonctions pour cela sont là
stringo:
Yedelkin:
la question est très pertinente et intéressante, pas seulement pour vous, mais ce n'est pas la seule à laquelle nous n'obtiendrons pas de réponse - c'est la politique. c'est celui qui paie le joueur de cornemuse qui décide de la musique.
Quel est l'intérêt de cacher des informations sur l'heure du serveur du championnat et la présence/absence de l'heure d'été ?
Par exemple, le serveur du championnat n'a pas encore été lancé.
Le fait que le serveur n'ait pas été lancé n'a rien à voir avec la thèse du "c'est celui qui paie qui décide". :) L'intérêt d'utiliser cette thèse que j'essayais de comprendre :)
Quel est le problème de définir soi-même le passage à l'heure d'hiver? Toutes les fonctions sont présentes
Oui, le problème semble être un peu différent. Si les transactions doivent être exécutées uniquement à 18h00 CET, il est très pratique que l'heure du serveur coïncide complètement avec l'heure CET, ou que l'heure d'été de la zone CET et l'heure du serveur soient synchronisées. Il vous suffit alors d'écrire une ligne comme "if(TimeCurrent()==18.00) - trade" dans le bloc de négociation, et vous n'avez pas à penser à vérifier si l'heure d'été est passée dans la zone CET et sur le serveur.
Je dois vérifier de toute façon, car j'ai décidé de commercer selon l'heure locale dans différents pays. Les Japonais, par exemple, ne passent pas à l'heure d'été. Si je veux effectuer des transactions de 12 h à 14 h (heure de Tokyo), je dois vérifier l'heure d'été sur mon serveur de négociation, car elle est déjà mise en œuvre dans mon serveur. Les Canadiens ont un calendrier légèrement différent pour l'heure d'été, etc.
Oui, le problème semble être un peu différent. Si les transactions ne doivent être effectuées qu'à 18h00 CET, il est très pratique que l'heure du serveur soit complètement identique à l'heure CET, ou que les passages à l'heure d'été dans la zone CET et l'heure du serveur soient synchronisés. Il vous suffit alors d'écrire une ligne comme "if(TimeCurrent()==18.00) - trade" dans le bloc de trade, et de ne pas penser à vérifier si l'heure d'été est passée dans la zone CET et sur le serveur.
Je dois vérifier de toute façon, car j'ai décidé d'essayer de commercer en fonction de l'heure locale dans différents pays. Les Japonais, par exemple, ne passent pas à l'heure d'été. Ainsi, pour pouvoir effectuer des transactions à 12h00, heure de Tokyo, je dois vérifier le retour de l'heure d'été sur le serveur (car il s'agit d'une fonction standard). Les Canadiens ont des délais de retour légèrement différents, etc.
Pas de problème. Vous savez quelle heure il est par rapport aux centres financiers, vous savez s'ils sont à l'heure d'été ou non (au moins vous pouvez le savoir), il est possible de calculer l'heure GMT.
Je ne vois pas de problème de calcul du temps pour aucun des centres financiers existants.
Le testeur de stratégie sera un peu délicat, mais c'est gérable.
Pas de problème. Les heures relatives des centres financiers sont connues, le passage ou non à l'heure d'été est également connu (du moins il est possible de le savoir), il est possible de calculer l'heure GMT en principe.
Je ne vois aucun problème à calculer le temps pour n'importe lequel des centres financiers existants.
Je ne dis pas que le fait de revenir à l'heure d'hiver est un problème. Mais, comparé à une ligne comme "if(TimeCurrent()==18.00) - trade", des lignes de code supplémentaires pour le suivi - n'ajoute aucune élégance ou vitesse au code :)
Oui, le problème semble être un peu différent. Si les transactions ne doivent être effectuées qu'à 18h00 CET, il est très pratique que l'heure du serveur soit complètement identique à l'heure CET, ou que les passages à l'heure d'été dans la zone CET et l'heure du serveur soient synchronisés. Il vous suffit alors d'écrire une ligne comme "if(TimeCurrent()==18.00) - trade" dans le bloc de négociation, et vous n'avez pas à penser à vérifier si l'heure d'été est passée dans la zone CET et sur le serveur.
Je dois vérifier de toute façon, car j'ai décidé de commercer selon l'heure locale dans différents pays. Les Japonais, par exemple, ne passent pas à l'heure d'été. Si je veux effectuer des transactions de 12 h à 14 h (heure de Tokyo), je dois vérifier l'heure d'été sur mon serveur de négociation, car elle est déjà mise en œuvre dans mon serveur. Les Canadiens ont un calendrier légèrement différent pour l'heure d'été, etc.
1) Que se passe-t-il si vous ne négociez pas le jour de l'échange ?
2. Voulez-vous avoir le contrôle ? Dans cette étude de cas, MQL5. Toutes les options permettant de déterminer le fait de passer à l'heure d'hiver sont présentées. Initialement.