Ich bin völlig verloren - Seite 5

Neuer Kommentar
 
Ich weiß nicht, was Sie mit statischer Besetzung meinen. Das Problem mit der Zeitzone ist ein Problem in mql. Mit alten mql4 der Ansatz war, eine globale Variablen, die der Benutzer auf die Makler Offset gesetzt haben, können Sie auch gmt Zeit mit der neuen timegmt Funktion erhalten, aber ich habe einige Berichte gesehen, das ist buggy. Ich bin mir auch nicht sicher, wie es sich beim Backtesting verhält. Die ganze Sache ist leider ein Chaos. Aber es ist nicht unmöglich, den Code zu umgehen.
 
RaptorUK: OK, welche Zeitzone ist eine Datumszeit von 0?
Es ist die Zeitzone des Servers Ihres Brokers. PERIOD. Jede Zeitangabe, die Sie von mt4 erhalten, entspricht der Zeitzone Ihres Servers. (Mit Ausnahme von TimeLocal() und dem neuen mt5 TimeGMT)
ydrol: Es ist mir ein Rätsel, wie die Entwickler von MQL4 darauf gekommen sind, UTC nicht für alle Datumsangaben vorzuschreiben,

Sie sind verwirrt über etwas, das über zehn Jahre alt ist? Haben Sie schon einmal von Y2K gehört? Wenn nicht, dann würde es Sie nur verwundern, warum Datumsangaben mit nur zwei Ziffern pro Jahr gespeichert wurden, so dass nach 1999 das Jahr 1900 oder 19100 war.

Sie fragen sich wahrscheinlich, warum die Anzahl der IP-Adressen auf 4,2 Milliarden in einer Welt mit 7 Milliarden Menschen begrenzt ist. Irgendjemand hat diese Entscheidung bei der DARPA getroffen, als es darum ging, die vorhandenen (Dutzende) Großrechner im Land zu verbinden. Jetzt stellen wir von IPv4 auf IPv6 um.

Überwinden Sie sich. Wir sind hier nicht bei Berger King, du bekommst nicht, was du willst. Jemand hat eine Entscheidung getroffen, die zu dem Zeitpunkt vernünftig erschien und es jetzt nicht mehr ist. Finden Sie sich damit ab.

 
zortharg:

ydrol, für die Liebe zu allem, was heilig ist oder was auch immer, bitte sagen Sie mir - wenn Sie wissen - wenn static_cast in mql4 verwendet werden kann! Ist es dasselbe wie in C++? Auf dieser Seite https://docs.mql4.com/basis/types/casting wird das nie erwähnt, ich kann es weder in den Foren noch sonstwo finden. Ich stoße in meiner Programmierung ständig auf Situationen, nicht nur bei der Umwandlung von datetime in long, sondern auch von datetime in double, wo es unvermeidlich ist, also möchte ich es richtig machen. Das Programm findet nämlich heraus, in welchem Teil der Woche sich eine Probe befindet, und hebt dies in seinen Berechnungen entsprechend hervor - aber die Zeit modulo der Anzahl der Sekunden in einer Woche ist immer noch eine Variable vom Typ datetime, und wenn ich sie nicht in etwas anderes umwandeln kann, bleibt sie so stecken. Ich muss aber eine mathematische Funktion mit ihr ausführen, damit sie am Ende ein Double ist, verstehen Sie? Wenn Sie es nicht wissen, dann machen Sie sich nichts draus, aber sagen Sie mir bitte, wenn Sie es wissen, wie ich Dinge in einer solchen Situation richtig typisieren soll.

In der Dokumentation gibt es einen ganzen Abschnitt über Datentypen und Typecasting Drücken Sie die F1-Taste, während Sie den Editor benutzen?

 
WHRoeder:
Es ist die Zeitzone des Servers Ihres Brokers. PERIOD. Jede Zeitangabe, die Sie von mt4 erhalten, entspricht der Zeitzone Ihres Servers. (Mit Ausnahme von TimeLocal() und dem neuen mt5 TimeGMT)

Sie sind verwirrt über etwas, das über zehn Jahre alt ist? Haben Sie schon einmal von Y2K gehört? Wenn nicht, wäre es Ihnen ein Rätsel, warum Daten mit nur zwei Ziffern pro Jahr gespeichert wurden, so dass nach 1999 das Jahr 1900 oder 19100 kam.

Sie fragen sich wahrscheinlich, warum die Zahl der IP-Adressen auf 4,2 Milliarden begrenzt ist, obwohl es 7 Milliarden Menschen gibt. Jemand bei der DARPA hat diese Entscheidung getroffen, als es darum ging, die vorhandenen (Dutzende) Großrechner im Land zu verbinden. Jetzt stellen wir von IPv4 auf IPv6 um.

Überwinden Sie sich. Wir sind hier nicht bei Berger King, du bekommst nicht, was du willst. Jemand hat eine Entscheidung getroffen, die zu dem Zeitpunkt vernünftig erschien und es jetzt nicht mehr ist. Finden Sie sich damit ab.

Nein, du musst dich selbst überwinden. Ernsthaft, ich bin verwundert, warum diese Entscheidung getroffen wurde, als sie entworfen wurde. Und es ist mein gutes Recht, das zu sagen. Freie Meinungsäußerung und so weiter. Du hast nicht das Recht, mich zu unterdrücken, genauso wenig wie ich dich. Es basiert auf einem etablierten Zeitformat, das aus einem bestimmten Grund bereits utc verwendet hat und weit älter als 10 Jahre ist, und jetzt hat mql4 Probleme mit der Zeitzone aufgrund einer Entscheidung, die mir offen gesagt ein Rätsel ist. Und ich darf das sagen. Sie können sich über das Jahr 2000 lustig machen, so viel Sie wollen, es macht keinen Unterschied. Ich arbeite seit fast zwanzig Jahren in der Systemintegration, und es scheint eine schlechte Entscheidung gewesen zu sein, die Zeitzone nicht auf UTC umzustellen. Tut mir leid, wenn Sie nicht damit umgehen können, dass jemand anderes seine Meinung äußert.
 
WHRoeder:
Es ist die Zeitzone des Servers Ihres Brokers. PERIOD. Jede Zeitangabe, die Sie von mt4 erhalten, ist die Zeitzone Ihres Servers. (Mit Ausnahme von TimeLocal() und dem neuen mt5 TimeGMT.
und GlobalVariableSet(), das die GMT-Zeit von der PC-Uhr ableitet (nicht modelliert)
 

Ich greife das nur deshalb wieder auf, weil ich gerade dabei bin, meine TimeZone/Session-Funktionen in eine ordentliche mql4++-Klasse zu überführen!

WHRoeder: Someone made a decision that seemed reasonable at the time and now isn't. Deal with it.

Ich kümmere mich darum, aber es ist mir immer noch ein Rätsel, warum ich das überhaupt tun muss! Bewährte Verfahren für die Verwaltung von Zeitzoneninformationen gibt es schon seit langem, nämlich seit 1988. Zum Beispiel für ISO 8601

Zeitzonen in ISO 8601 werden als Ortszeit (ohne Angabe des Ortes), als UTC oder als Abweichung von UTC dargestellt.

Wird bei einer Zeitangabe keine UTC-Beziehung angegeben, wird davon ausgegangen, dass die Zeit in Ortszeit angegeben ist. Während die Annahme der Ortszeit bei der Kommunikation in derselben Zeitzone sicher sein mag, ist sie bei der Kommunikation über verschiedene Zeitzonen hinweg mehrdeutig. Es ist normalerweise vorzuziehen, eine Zeitzone (Zonenkennung) unter Verwendung der Notation des Standards anzugeben."

Das unterstrichene Bit ist in der IT seit fast 30 Jahren bekannt, wenn nicht noch länger. Das MQL-Datumsformat ist von UnixTime abgeleitet (sie haben das magische Datum 1.1.1970 nicht aus der Luft gegriffen), also sollte ihnen das inzwischen bekannt sein.

Ebenfalls 1988 ratifizierte POSIX die UnixTime

"Das POSIX-Komitee ließ sich von Argumenten gegen die Komplexität der Bibliotheksfunktionen leiten, und definierte die Unix-Zeit auf einfache Weise in Form der Elemente der UTC-Zeit. [Hervorhebung von mir]

Systemarchitekten oder Entwickler, die vor 10 Jahren (was noch gar nicht so lange her ist) Client-Server-Systeme entwarfen, die zeitkritische Informationen austauschen, hätten genügend Informationen haben müssen, um das derzeitige Zeitzonen-Durcheinander vorauszusehen/zu vermeiden. Händler in einer Zeitzone erhalten Daten in einer anderen Zeitzone, die sie manchmal in einer anderen Zeitzone interpretiert haben wollen (z.B. NY). Die einzigen Ausreden sind:

- Unwissenheit

- niedrige Priorität (die TZ-Verwirrung kommt den Brokern zugute, nicht den Händlern?)

- irgendeine technische Überlegung/Einschränkung/Anforderung, die für uns Außenstehende nicht offensichtlich ist. Vielleicht Diagramme zeichnen oder so? Obwohl es nicht so schwer ist, einen bekannten Offset zu addieren/subtrahieren?

Alle oben genannten Punkte verwirren mich, wie ich bereits sagte. Ich denke, ich sollte keinen Code schreiben müssen, um die GMT-Zeit während des Backtestings zu berechnen! Aber TimeGMT() und TimeLocal() sind nicht korrekt modelliert (sie sind beide auf die unspezifische TZ gesetzt, die aus historischen Daten abgeleitet wurde), so dass wir unsere eigenen Zeitzonenfunktionen schreiben müssen, um UTC und damit die Start- und Endzeiten der Sitzungen während des Backtestings genau zu berechnen.

PS: Die Ironie, dass mir WHRoeder gesagt hat, ich solle mich überwinden", ist nicht verloren gegangen :)

12345
Neuer Kommentar