Sortie à Londres - 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
Oui, tout cela à cause d'une décision de conception déroutante:) Il se peut donc que l'heure du serveur ne corresponde à aucune horloge mondiale connue au cours d'une année.
J'ai une méthode pour déterminer avec précision l'heure GMT, notamment lors des backtests. Cette méthode semble fonctionner pour les courtiers qui
mais l'approche me semble toujours un peu bricolée.
Il s'agissait de télécharger des cotations basées sur l'heure GMT à partir d'autres sources (dukascopy), et de comparer l'heure de chaque sommet quotidien. Cela fonctionne bien pour le backtesting, mais pour l'instant je télécharge manuellement les données horaires et je filtre les sommets (en utilisant un script perl).
Dès que je pourrai obtenir automatiquement des cotations GMT H1 à partir d'au moins deux sources, je serai à l'aise avec cette approche pour mes besoins.
Comment MT4 pourrait-il être plus adapté à cette tâche ? Je ne sais pas pour vous, mais je ne me réjouirais pas de la création d'un calculateur de décalage GMT historique régional. Pouvez-vous imaginer ? omg. Si jamais je le fais, je le mettrai sur le marché, vous avez intérêt à avoir un gros carnet de chèques ;)
Un calculateur de décalage historique GMT n'est pas en soi particulièrement difficile (le système d'exploitation Windows contient déjà toutes les données dont vous avez besoin), mais ce n'est pas le problème principal. Le problème est que vous pouvez déterminer le décalage actuel entre l'heure du courtier et l'heure GMT, mais vous ne savez pas si/quand il a changé. En utilisant l'exemple ci-dessus, vous pouvez voir que le courtier est actuellement à GMT+3 (en supposant que l'horloge de l'ordinateur local est exacte...), mais vous ne savez pas que le courtier était à GMT+2 la semaine dernière.
Il est très possible que le terminal client MT4 ne dispose tout simplement pas de cette information.
S'il en disposait, MT4 pourrait fournir soit les données brutes que vous pourriez traiter vous-même, soit une fonction qui vous permettrait de dire "convertir en GMT n'importe quelle date du courtier dans le passé". Une fois que vous avez obtenu cette information, vous pouvez utiliser une table de consultation (ou l'API Windows) pour convertir cette heure GMT historique en un autre fuseau horaire tel que Londres. Toutefois, il serait préférable que MT4 le fasse également pour vous, par exemple au moyen d'une paire de fonctions comme la suivante :
datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone) ;
datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone) ;
Oui, tout cela à cause d'une décision de conception déroutante de l'OMI :)
(Je suppose que la raison pour ne pas fixer sur UTC est que les courtiers peuvent fonctionner à EET donnant cinq bougies D1 par semaine, évitant une sixième petite bougie qui conduit à des sous-estimations systémiques de choses comme l'ATR D1 sur les courtiers qui utilisent GMTZ).
J'aurais mis tout ça dans le client, mais ça rend le client plus compliqué à différents endroits :) Mais au moins, toutes les variables sont connues.
Une autre approche, selon cette page , il n'y a que 62 courtiers MT4 ? Il ne serait donc pas trop difficile d'avoir une table de recherche pour chaque courtier et leur définition du temps (qu'elle soit basée sur un fuseau horaire réel ou une combinaison comme FXCM), et aussi d'incorporer les changements historiques (comme Alpari).
C'est probablement l'approche la plus robuste, et il faudra juste l'ajuster chaque fois qu'un courtier décidera d'embrouiller un peu plus ses clients :)
gchrmt4:
[1] L'heure de votre serveur, GMT+3, peut correspondre à l'heure de l'Est dans le sens où l'heure de l'Est est GMT+3 mais, selon Wikipedia et worldclock.com, nulle part ne devrait encore être à l'heure de l'Est. Ce changement ne devrait pas avoir lieu avant le 30 mars. L'heure actuelle à Chypre, en Grèce, en Israël, etc. est GMT+2.
[2] Par conséquent, vous avez probablement affaire à un courtier qui fait fonctionner ses serveurs à GMT+2, mais qui passe à l'heure d'été aux dates américaines plutôt qu'aux dates européennes.
[3] Ce n'est pas la même chose que EET/EEST. (Et c'est encore moins prévisible en termes de possibilité d'écrire un code qui ajuste automatiquement les heures et les dates sans avoir à demander à l'utilisateur une sorte d'entrée sur les paramètres horaires utilisés par le courtier).
Un courtier ne change généralement pas souvent le fuseau horaire de son serveur, sauf pour s'adapter à l'heure d'été. Pour l'ajustement de l'heure d'été, je peux utiliser n'importe quelle date/heure (de 1987 (États-Unis) et 1996 (UE) à 2020 et au-delà) et calculer, pour les États-Unis et l'UE, le jour où l'heure d'été commence et le jour où elle se termine. Une fois que vous avez ce code, il ne vous reste plus qu'à ajuster le décalage actuel par rapport à l'heure GMT pour tenir compte de l'heure d'été pour l'heure que vous regardez.
Avec TimeGMT(), qui est nouveau dans la version 600+, vous calculez le décalage actuel de votre courtier par rapport à GMT. Mais on ne peut pas (pour autant que je sache) déterminer le fuseau horaire d'un courtier à partir du passé. Par exemple, j'ai eu un courtier qui a changé le fuseau horaire de son serveur de GMT pour l'heure standard à GMT+2 pour l'heure standard. J'ai traité ce problème en codant en dur un décalage pour le temps avant le changement parce que toutes les données de l'historique étaient GMT, et non GMT+2 (et je ne voulais pas modifier l'historique pour refléter GMT+2). À cet égard, je crois que vous et moi sommes d'accord. Tant qu'un courtier ne change pas simplement de fuseau horaire (sauf pour s'adapter à l'heure d'été), vous devriez pouvoir calculer le décalage par rapport à GMT et l'adapter à l'heure d'été.
Tout ce que je dis, c'est que l'information qu'il est possible d'obtenir à partir de MT4 lui-même - le décalage actuel entre l'heure du courtier et l'heure GMT - est inadéquate en pratique pour faire des choses comme "calculer le prix d'ouverture à Londres mercredi dernier".
Je crois que je ne suis pas d'accord avec vous. Tant que le courtier ne change pas de fuseau horaire, sauf pour s'adapter à l'heure d'été, vous pouvez déterminer le décalage par rapport à GMT, tant pour l'heure actuelle que pour l'heure historique. Si, la semaine dernière, pendant l'heure normale, le courtier est à GMT+2 et Londres à GMT, alors 8 heures du matin à Londres correspondraient à 10 heures du matin sur le serveur. Le mois prochain, pendant l'heure d'été, lorsque le courtier est à GMT+3 et que Londres est à GMT+1, 8 heures du matin à Londres correspondraient à 10 heures du matin à l'heure du serveur. Aujourd'hui, alors que le courtier est à l'heure d'été et que Londres est à l'heure normale, le courtier est à GMT+3 et Londres à GMT, de sorte que l'heure de Londres à 8 heures correspond à l'heure du serveur à 11 heures.
Si le courtier est à l'heure GMT-5 (EST) et que Londres est à l'heure GMT, l'heure de 8h à Londres correspond à l'heure du serveur de 3h.
Un calculateur historique de l'heure GMT n'est pas en soi particulièrement difficile (le système d'exploitation Windows contient déjà toutes les données dont vous avez besoin), mais ce n'est pas le problème principal. Le problème est que vous pouvez déterminer le décalage actuel entre l'heure du courtier et l'heure GMT, mais vous ne savez pas si/quand il a changé. En utilisant l'exemple ci-dessus, vous pouvez voir que le courtier est actuellement à GMT+3 (en supposant que l'horloge de l'ordinateur local est exacte...), mais vous ne savez pas que le courtier était à GMT+2 la semaine dernière.
Il est très possible que le terminal client MT4 ne dispose tout simplement pas de cette information.
S'il en disposait, MT4 pourrait fournir soit les données brutes que vous pourriez traiter vous-même, soit une fonction qui vous permettrait de dire "convertir en GMT n'importe quelle date du courtier dans le passé". Une fois que vous avez obtenu cette information, vous pouvez utiliser une table de consultation (ou l'API Windows) pour convertir cette heure GMT historique en un autre fuseau horaire tel que Londres. Toutefois, il serait préférable que MT4 le fasse également pour vous, par exemple au moyen d'une paire de fonctions comme la suivante :
datetime ConvertToBrokerTime(datetime HistoricRegionalTime, SortSortOfTimeZoneInfo FromTimeZone) ;
datetime ConvertFromBrokerTime(datetime HistoricBrokerTime, SortSortOfTimeZoneInfo ToTimeZone) ;
Oui, ce ne serait pas difficile s'il n'y avait pas de DST, mais il y a lol... ce serait un cauchemar à coder. Les anomalies historiques seraient partout. Des régions qui ont changé le fuseau horaire qu'elles utilisent, des régions qui ont essayé de ne pas utiliser l'heure d'été puis sont revenues à l'heure d'été, des régions qui respectent l'heure d'été à certains endroits mais pas à d'autres, il y aurait tellement d'anomalies à prendre en compte, partout dans le monde...
Une autre approche, selon cette page , il n'y a que 62 courtiers MT4 ? Il ne serait donc pas trop difficile d'avoir une table de recherche pour chaque courtier et leur définition de l'heure (qu'elle soit basée sur un fuseau horaire réel ou une combinaison comme FXCM), et également d'incorporer les changements historiques (comme Alpari).
Thirteen:
Si, la semaine dernière, en heure normale, le courtier est en GMT+2 et Londres en GMT,
L'approche de bon sens serait que le serveur MT4 utilise toujours le GMT, mais vous savez qu'il ne le fera pas.