Je suis complètement perdue - page 4
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
Le fuseau horaire pour datetime (secondes après 1970) est basé sur UTC. Tout comme le temps Unix. C'est UnixTime - le temps Unix 64 bits.
datetime - datetime = long (durée en secondes)
datetime +/- secondes(long) = datetime(autre date)
datetime +/- secondes(int) = datetime(autre date)
S'il vous plaît, ne nourrissez pas le troll.
Lorsque vous répondez, vous donnez du pouvoir au troll. Lorsque vous ignorez le troll, il a besoin d'attention et finit par mourir.
Je pense que vous avez fait une excellente contribution. Vos posts sont concis et bien enseignés et vous recevez beaucoup de résolutions de "merci" pour vos efforts.
Oui, je pense que vous avez fait tout ce que vous pouviez pour ce type.
Comment spécifier une date en GMT ?
whoop oublié que mql4 utilise un concept de temps cassé, . Je reconnais la question rhétorique :-) le fuseau horaire dépend de l'endroit d'où il provient. D'où tous les problèmes car il y a de multiples sources : courtier, ordinateur, backtesting bla bla.
J'avais peur que les règles de promotion des types de données fonctionnent de cette façon. Ok, donc :
datetime - datetime = long (durée en secondes)
datetime +/- secondes(long) = datetime(autre date)
datetime +/- secondes(int) = datetime(autre date)
Mais si je dis X=Y-Z, ou (Y-Z)/60, ou quelque chose comme ça, où X est déjà déclaré comme un long ou un int, et Y et Z sont des dates, est-ce très, très mauvais ? Et si c'est le cas, est-ce que static_cast peut tout régler ?
Raptoruk, ce n'est pas indépendant du fuseau horaire. Bien sûr, la différence entre 14 h et 15 h est de 3600 dans un fuseau horaire donné. Mais que se passe-t-il si je sais que la négociation s'arrête à 17 heures, heure de l'Est, le vendredi, mais que je ne sais pas dans quel fuseau horaire se trouve l'heure 0 (minuit le 1er janvier 1970) ? Nous avons alors un problème, n'est-ce pas ? Le 1er janvier 1970 était donc un jeudi. Si le temps 0 est en GMT, alors la négociation s'arrête 46 heures après, soit 165600 modulo 604800. En d'autres termes, avec 604800 secondes dans une semaine, j'utilise l'opération arithmétique X%604800 pour le reste en divisant par 604800, et le trading s'arrête à 165600. Cependant, si le courtier se trouve à deux fuseaux horaires à l'est et que sa camelote est horodatée avec une valeur supérieure de 7200, alors la négociation s'arrête lorsque le time%604800 est de 172800, et non de 165600.
Il semble qu'il y ait une incertitude sur les indices de temps déclarés. Je suppose que je dois faire en sorte que mon code calcule les heures modulo 604800 auxquelles la négociation commence et s'arrête après tout, juste pour être sûr. Je pense que je regarde quelque chose comme iTime('USDJPY',60,X) et que je trouve des écarts de 48 heures. Je peux compter sur iTime comme étant l'heure d'ouverture, le DÉBUT de l'heure, n'est-ce pas ? En d'autres termes, le trading s'arrête 1 heure après le dernier indice horaire avant un gap de 2 jours, et il reprend exactement au début du premier après le gap, et ensuite l'ajout de multiples de 604800 change simplement la semaine. Cependant, il y aurait des complications supplémentaires, comme par exemple si dans une semaine, il manque la dernière heure, ou la première heure. Peut-être utiliser iTime('USDJPY',1,X) pour que je sois décalé de quelques minutes au maximum.
Oh wow, beaucoup de messages déclenchés si rapidement par celui-là. Juste pour que quelqu'un d'autre sache, je suppose que raptoruk est ok après tout, mais un tas d'invectives n'est pas le bienvenu, donc si vous n'êtes pas ydrol ou raptoruk ou quelqu'un de nouveau avec quelque chose de nouveau à dire, arrêtez simplement de poster, je ne suis pas un troll parce que je ne me soucie pas de vos états émotionnels d'une manière ou d'une autre et si vous avez quelque chose de plus à jeter autour, sachez que cela tombe sur des oreilles sourdes.
J'avais peur que les règles de promotion des types de données fonctionnent de cette façon. Ok, donc :
datetime - datetime = long (durée en secondes)
datetime +/- secondes(long) = datetime(autre date)
datetime +/- secondes(int) = datetime(autre date)
Mais si je dis X=Y-Z, ou (Y-Z)/60, ou quelque chose comme ça, où X est déjà déclaré comme un long ou un int, et Y et Z sont des dates, est-ce très, très mauvais ? Et si c'est le cas, est-ce que static_cast va tout régler ?
Raptoruk, ce n'est pas indépendant du fuseau horaire.
Mais que faire si je sais que la négociation s'arrête à 17 heures, heure de l'Est, le vendredi, mais que je ne sais pas dans quel fuseau horaire se trouve l'heure 0 (minuit le 1er janvier 1970) ? Nous avons alors un problème, n'est-ce pas ?
J'avais peur que les règles de promotion des types de données fonctionnent de cette façon. Ok, donc :
datetime - datetime = long (durée en secondes)
datetime +/- secondes(long) = datetime(autre date)
datetime +/- secondes(int) = datetime(autre date)
Mais si je dis X=Y-Z, ou (Y-Z)/60, ou quelque chose comme ça, où X est déjà déclaré comme un long ou un int, et Y et Z sont des dates, est-ce très, très mauvais ? Et si c'est le cas, est-ce que static_cast va tout régler ?
Il ne s'agit pas de "règles de promotion", mais simplement de mon bon sens (je l'espère !). Je ferais généralement moi-même les typologies ci-dessus.
Si le résultat de mon calcul est toujours un nombre de secondes depuis le 1/1/1970 (indépendamment du fuseau horaire ou de l'absence de fuseau horaire), je le conserverais sous forme de datetime.
Sinon, tout autre résultat (une durée, des minutes depuis le 1/1/1970, etc.) sera probablement stocké sous forme de long. (Parfois un int, en particulier pour les durées typiques, etc.)
Ceci dit, je me demande comment les concepteurs de MQL4 sont arrivés à ne pas imposer l'UTC pour toutes les dates, et à forcer tous les courtiers à envoyer des données UTC, et à laisser le client les interpréter en heure locale, parce que leur approche actuelle complique inutilement tout en aval.
Cela rend le calcul de l'heure GMT et des heures d'ouverture/de fermeture des sessions pendant le backtesting plus difficile qu'il ne devrait l'être, si vous voulez le faire correctement pour toutes les sources de données tick.
(Par exemple, Alpari a plusieurs fuseaux horaires dans ses données historiques, vous devez donc faire attention à vos sources de données lors du backtesting).
PS J'ai corrigé mon erreur précédente :)
ydrol, pour l'amour de tout ce qui est sacré ou quoi que ce soit, dites-moi s'il vous plaît - si vous le savez - si static_cast peut être utilisé dans mql4 ! Est-ce la même chose qu'en C++ ? Cette page https://docs.mql4.com/basis/types/casting ne le mentionne jamais, je ne le trouve pas dans les forums, je ne le trouve nulle part. Je me heurte constamment à des situations dans mon codage, pas seulement en transformant la date en long, mais la date en double, où c'est inévitable, donc je veux le faire correctement. Le programme détermine la partie de la semaine dans laquelle se trouve un échantillon, et l'accentue dans ses calculs en conséquence - mais le temps modulo le nombre de secondes dans une semaine est toujours une variable de type datetime et à moins que je puisse le convertir en quelque chose d'autre, il est coincé de cette façon. Mais j'ai besoin d'exécuter une fonction mathématique sur cette variable et de la transformer en un double à la fin, vous voyez. Si vous ne le savez pas, ne vous inquiétez pas, mais si vous le savez, dites-moi comment je dois encoder correctement les choses dans ce genre de situation.
raptoruk, "Non... peut-être que vous le faites, je ne le fais pas, donc non, nous ne le faisons pas." C'est absolument un problème. Pas pour moi, pas pour vous, pas pour nous, mais pour la validité de votre déclaration précédente que c'est indépendant du fuseau horaire. Parce que peu importe le fuseau horaire de votre courtier, le trading sur le forex ne suit pas l'horloge de votre courtier. C'est 17h Eastern le vendredi et le dimanche. 10 heures GMT. Et qu'en est-il de l'heure d'été et de l'heure normale ? Qu'en est-il de CELA ! Certains pays n'ajoutent pas d'heure ou la soustraient, ou bien ils le font un jour différent, donc vous pourriez vous retrouver avec un code décalé d'une heure pendant certaines parties de l'année, s'il n'y a pas une façon agréable de le faire. Moi, je n'ai pas encore choisi de courtier. Celui que j'essaie est en GMT+2 mais je pense maintenant que je ne les aime pas, sur la base de leur compte de démonstration. Et si j'en essaie un pour de vrai, peut-être que je voudrai en utiliser un autre à la place. Je ne veux donc pas que le fuseau horaire du courtier soit codé en dur dans le programme s'il est facile de ne pas le faire. Ne soyez pas encore comme cet autre type, qui essaie de tout déformer pour en faire une occasion de lancer une insulte au lieu de prendre la question au pied de la lettre.