temps dans le terminal aux championnats - page 10

 
autoforex: D'après mes observations, il est égal à l'heure du serveur de cotation, c'est-à-dire SET (pour le serveur de cotation).
Merci ! Lorsque mon optimisation sera terminée (et il faudra bien qu'elle le soit un jour), j'essaierai de vérifier ce qui s'y passe vraiment.
 
autoforex:
Il retournera l'heure de la bougie actuelle = CurrentTime(). C'est facile à vérifier.

Oui, je m'en occupe. Il y a un an j'ai écrit quelques fonctions qui par trois eaux (peut être réduit à deux) déterminent l'heure GMT actuelle pour n'importe quel chandelier.

Les données importantes sont : le fuseau horaire du serveur (indiqué par un écart en heures par rapport à GMT) et le type de transition hiver/été (Non/Europe/USA).

Je veux juste dire que ce n'est clairement pas une option à deux cordes et loin d'être universelle.

PS

Les développeurs sont trop paresseux même pour informer ces "entrées" que je dois spécifier moi-même, alors que le calcul duplique et réécrit beaucoup de code.

Le point est le suivant.

Документация по MQL5: Дата и время / TimeCurrent
Документация по MQL5: Дата и время / TimeCurrent
  • www.mql5.com
Дата и время / TimeCurrent - Документация по MQL5
 
Yedelkin:

Votre conclusion contredit vos propres observations :) Tout d'abord, vous observez que TimeCurrent()==22.00==TimeGMT(), mais vous ne voulez pas admettre que TimeCurrent()==TimeGMT() dans le testeur. C'est-à-dire que vous ne voulez pas admettre que l'heure du serveur coïncide avec l'heure GMT dans le testeur.


C'est le cas, c'est toute la "mésaventure".

Si nous parlons du testeur, il est évident que "quelqu'un croit" que tous les PC fonctionnent à l'heure du serveur et que tous les serveurs sont dans la zone GMT.

Dans ce cas, la transition hiver/été et il ne peut y en avoir une.

Yedelkin:

Excellente conclusion à l'appui de votre position :) - C'est la faute du testeur :)


La faute n'incombe pas au testeur, mais à ceux qui ont "inventé" de lier tout le temps (absolument tout) au temps des citations.

Dans ce cas, ni dans le testeur ni dans l'environnement de négociation, il n'y a aucune information sur la zone dans laquelle se trouve le serveur de négociation et sur le changement d'heure.

Il semble très difficile d'ajouter deux paramètres supplémentaires, par exemple, dans AccountInfoInteger et de modifier le comportement de TimeGMT dans le testeur (afin que le résultat soit corrigé en fonction de la zone du serveur).

Yedelkin:
Merci ! Lorsque mon optimisation sera terminée (et il faudra bien qu'elle le soit un jour), j'essaierai de vérifier ce qui s'y passe vraiment.

Ce qui se passe ici est simple, l'heure locale et l'heure GMT sont "égalisées" avec l'heure du serveur et TimeGMTOffset prétend que le changement d'heure hiver/été n'a jamais existé.

Donc, au moins le comportement de deux fonctions TimeGMTOffset et TimeGMT dans le testeur devrait être modifié. IMHO

 
Interesting: Si nous parlons du testeur, il est évident que "quelqu'un pense" que tous les PC fonctionnent à l'heure des serveurs, et que tous les serveurs sont dans la zone GMT.

Bon sujet sur l'histoire du temps dans le testeur ! Personnellement, je pensais naïvement que si l'heure du serveur est définie comme GMT+0, les citations ne seront stockées qu'au format GMT+0. Maintenant, nous devrons vérifier ce point et l'ajuster à la réalité du testeur, si nécessaire.

 
Yedelkin:
Bon sujet sur l'histoire du temps dans le testeur ! Personnellement, j'ai supposé naïvement que si l'heure du serveur dans le test était GMT+0, les guillemets seraient stockés dans le format GMT+0. Maintenant, nous devrons vérifier ce point et l'ajuster à la réalité du testeur, si nécessaire.

Je le fais depuis un an maintenant, je ne peux rien faire sans lui dans mon testeur.

Je n'ai jamais touché à l'"heure locale" dans le testeur, mais je pense que je vais devoir le faire.

À mon avis, pour un travail normal dans le testeur, vous devriez spécifier la zone et la possibilité de transition hiver/été (pour l'heure "locale") dans les paramètres, et les paramètres du serveur prennent de l'environnement commercial.

C'est-à-dire, idéalement, en fonction des données qui, dans l'environnement commercial et les cotations horaires, permettent de déterminer l'heure GMT, puis sur la base de l'heure GMT et des paramètres du testeur, de déterminer l'heure locale.

Mais les développeurs ne le feront pas, car seuls deux ou trois commerçants en ont "besoin".

 
Interesting: Ce qui se passe ici est une chose simple, l'heure locale et l'heure GMT sont "assimilées" à l'heure du serveur, et TimeGMTOffset prétend que la transition hiver/été n'a jamais existé.

Je suis au courant de cette fonctionnalité. J'ai supposé que c'était là, donc c'est assez satisfaisant jusqu'à présent. Mais si le fait d'assimiler l'heure GMT dans le testeur à l'heure du serveur (selon votre terminologie) entraîne une sorte de saut temporel, je devrai affiner le code.

 
Interesting: .. parce que deux ou trois commerçants sur l'ensemble des commerçants en ont "besoin".
Êtes-vous toujours prêt à obtenir cette phrase immortelle à l'avance aussi ? :) :):)
 
Yedelkin:
Êtes-vous toujours prêt à obtenir cette phrase immortelle à l'avance aussi ? :) :):)
Il y a des choses que l'on préfère faire par soi-même (même si c'est dans le désordre avec des béquilles) plutôt que d'attendre "la grâce de la nature"...
 
Interesting:
Il y a des choses qu'il vaut mieux mettre en œuvre par soi-même (même si c'est un gâchis avec des béquilles) que d'attendre "la grâce de la nature"...
Avez-vous écrit au Service Desk à propos de ce problème particulier ? Y a-t-il eu une réponse ? Si un tel problème se pose, il ne concerne pas deux ou trois personnes mais tous ceux qui utilisent le testeur. )))
 
tol64:
Avez-vous écrit au Service Desk à propos de ce problème particulier ? Y a-t-il eu une réponse ? Si un tel problème existe, ce n'est pas un problème pour deux ou trois personnes, mais pour tous ceux qui utilisent le testeur. )))
J'ai écrit, mais apparemment les étoiles étaient dans le mauvais signe à ce moment-là.
Raison: