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
Vous êtes perplexe face à quelque chose qui a plus de dix ans ? Avez-vous déjà entendu parler du bogue de l'an 2000 ? Si ce n'est pas le cas, vous ne savez pas pourquoi les dates sont stockées avec seulement deux chiffres par année, donc après 1999, c'est l'année 1900 ou 19100.
Vous vous demandez probablement pourquoi les adresses IP sont limitées à 4,2 milliards dans un monde de 7 milliards d'habitants. Quelqu'un a pris cette décision au DARPA en essayant de connecter les (dizaines) ordinateurs centraux existants dans le pays. Maintenant, nous passons de l'IPv4 à l'IPv6.
Reprenez-vous. Ce n'est pas Berger King, tu n'auras pas ce que tu veux. Quelqu'un a pris une décision qui semblait raisonnable à l'époque et qui ne l'est plus maintenant. Il faut faire avec.
ydrol, pour l'amour de tout ce qui est sacré ou autre, dis-moi - si tu le sais - 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 faire pour encoder correctement les choses dans ce genre de situation.
Il y a toute une section dans la documentation sur les types de données et le typage. Appuyez vous sur F1 lorsque vous utilisez l'éditeur ?
C'est le fuseau horaire du serveur de votre courtier. PÉRIODE. Toute date que vous obtenez de mt4 est le fuseau horaire de votre serveur. (A l'exception de TimeLocal() et du nouveau mt5 TimeGMT).
Vous êtes perplexe face à quelque chose qui a plus de dix ans ? Avez-vous déjà entendu parler du bogue de l'an 2000 ? Si ce n'est pas le cas, vous vous demandez pourquoi les dates sont enregistrées avec seulement deux chiffres par année, de sorte qu'après 1999, on parle de l'année 1900 ou 19100.
Vous vous demandez probablement pourquoi les adresses IP sont limitées à 4,2 milliards dans un monde de 7 milliards d'habitants. Quelqu'un a pris cette décision à la DARPA en essayant de connecter les (dizaines) ordinateurs centraux existants dans le pays. Maintenant, nous passons de l'IPv4 à l'IPv6.
Reprenez-vous. Ce n'est pas Berger King, tu n'auras pas ce que tu veux. Quelqu'un a pris une décision qui semblait raisonnable à l'époque et qui ne l'est plus maintenant. Il faut faire avec.
Il s'agit du fuseau horaire du serveur de votre courtier. PERIODE. Toute date que vous obtenez de mt4 est le fuseau horaire de votre serveur. (A l'exception de TimeLocal() et du nouveau mt5 TimeGMT.
Je remets cela sur le tapis uniquement parce que je suis en train de migrer mes fonctions TimeZone/Session vers une classe mql4++ bien ordonnée !
WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.
Je m'en occupe, mais je ne comprends toujours pas pourquoi je dois le faire en premier lieu ! Les meilleures pratiques en matière de gestion des informations sur les fuseaux horaires existent depuis longtemps, depuis 1988. Par exemple pour la norme ISO 8601
Dans la norme ISO 8601, lesfuseaux horaires sont représentés sous forme d'heure locale (le lieu n'étant pas précisé), d'UTC ou de décalage par rapport à l'UTC.
Si aucune information sur la relation UTC n'est donnée avec une représentation de l'heure, l'heure est supposée être en heure locale. S'il peut être sûr de supposer l'heure locale lors d'une communication dans le même fuseau horaire, cela est ambigu lorsqu'il s'agit de communiquer à travers différents fuseaux horaires[C'est moi qui souligne] Il est généralement préférable d'indiquer un fuseau horaire (indicateur de fuseau) en utilisant la notation de la norme."
Le bit souligné est connu en informatique depuis près de 30 ans, si ce n'est plus. Le format de date MQL est dérivé d'UnixTime (ils n'ont pas arraché la date magique du 1/1/1970), ils devraient donc être au courant de cela depuis longtemps.
Encore une fois en 1988, POSIX a ratifié UnixTime
"Le comité POSIX a été influencé par les arguments contre la complexité des fonctions de la bibliothèque, et a fermement défini le temps Unix d'une manière simple en termes d'éléments du temps UTC. (C'est moi qui souligne)
Les architectes système ou les développeurs concevant des systèmes client-serveur il y a 10 ans (ce qui n'est même pas si loin), qui échangent des informations critiques en termes de temps, auraient dû avoir suffisamment d'informations pour anticiper/éviter le désordre actuel des fuseaux horaires. Les opérateurs d'un fuseau horaire reçoivent des données dans un autre fuseau horaire, qu'ils souhaitent parfois voir interprétées dans un autre fuseau horaire (par exemple NY). Les seules excuses sont
- l'ignorance
- une faible priorité (la confusion des fuseaux horaires profite aux courtiers et non aux opérateurs).
- une considération/contrainte/exigence technique qui n'est pas évidente pour nous de l'extérieur. Peut-être en dessinant des diagrammes ou autre chose ? Bien que ce ne soit pas si difficile d'ajouter/soustraire un décalage connu?
Tout ce qui précède me laisse perplexe, comme je l'ai déjà dit. Je ne devrais pas avoir besoin d'écrire du code pour calculer l'heure GMT pendant le backtesting ! Mais TimeGMT() et TimeLocal() ne sont pas correctement modélisés, (ils sont tous deux réglés sur le TZ non spécifique dérivé des données historiques). Nous devons donc créer nos propres fonctions de fuseau horaire, pour calculer avec précision l'heure UTC et donc les heures de début et de fin de session pendant le backtesting.
PS L'ironie du fait que WHRoeder m'ait dit de "me ressaisir" n'est pas perdue :)