Ich bin völlig verloren - Seite 4
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Die Zeitzone für datetime (Sekunden nach 1970) basiert auf UTC. Genau wie die Unix-Zeit. Es ist UnixTime - 64 Bit Unix-Zeit.
datetime - datetime = long (Sekunden Dauer)
datetime +/- Sekunden(long) = datetime(anderes Datum)
datetime +/- Sekunden(int) = datetime(ein anderes Datum)
Bitte füttern Sie den Troll nicht.
Wenn du antwortest, gibst du dem Troll Macht. Wenn du den Troll ignorierst, hungert er nach Aufmerksamkeit und stirbt schließlich.
Ich denke, Sie haben einen ausgezeichneten Beitrag geleistet. Ihre Beiträge sind prägnant und gut durchdacht, und Sie erhalten eine Menge "Dankeschön"-Resolutionen für Ihre Bemühungen.
Ja, ich denke, Sie haben alles getan, was Sie können für diesen Kerl.
Wie gebe ich ein Datum in GMT an?
whoop vergaß mql4 verwendet ein gebrochenes Konzept der Zeit, . Ich concede die rhetorische q :-) die Zeitzone hängt davon ab, woher es kam. daher alle Probleme, da es mehrere Quellen Broker, Computer, Backtesting blah blah
Ich hatte schon befürchtet, dass die Regeln für die Datentyp-Promotion so funktionieren würden. Ok, also:
datetime - datetime = long (Sekunden Dauer)
datetime +/- Sekunden(long) = datetime(ein anderes Datum)
datetime +/- Sekunden(int) = datetime(ein anderes Datum)
Aber wenn ich X=Y-Z oder (Y-Z)/60 oder so etwas sage, wobei X bereits als long oder int deklariert ist und Y und Z Datumswerte sind, ist das dann sehr, sehr schlecht? Und wenn ja, würde static_cast alles in Ordnung bringen?
Raptoruk, es ist nicht zeitzonenunabhängig. Natürlich beträgt die Differenz zwischen 14 Uhr und 15 Uhr in jeder Zeitzone 3600. Was aber, wenn ich weiß, dass der Handel am Freitag um 17 Uhr östlicher Zeit endet, ich aber nicht weiß, in welcher Zeitzone die Zeit 0 (Mitternacht am 1. Januar 1970) liegt? Dann haben wir ein Problem, nicht wahr! Der 1. Januar 1970 war also ein Donnerstag. Wenn die Zeit 0 in der GMT liegt, dann endet der Handel 46 Stunden danach, oder 165600 modulo 604800. Mit anderen Worten, bei 604800 Sekunden in einer Woche verwende ich die Rechenoperation X%604800 für den Rest bei der Division durch 604800, und der Handel endet bei 165600. Wenn der Broker jedoch 2 Zeitzonen weiter östlich liegt und seine Daten mit einem Zeitstempel versehen sind, der 7200 höher ist, dann endet der Handel, wenn time%604800 172800 ist, nicht 165600.
Es sieht so aus, als gäbe es Unsicherheiten bei den gemeldeten Zeitindizes. Ich denke, ich muss meinen Code die Zeiten modulo 604800 herausfinden lassen, zu denen der Handel beginnt und endet, nur um sicher zu sein. Ich denke, ich schaue mir etwas wie iTime('USDJPY',60,X) an und finde Lücken von 48 Stunden. Ich kann mich darauf verlassen, dass iTime die "offenen" Zeiten sind, der BEGINN der Stunde, richtig? Mit anderen Worten, der Handel endet 1 Stunde nach dem letzten Zeitindex vor einer 2-Tages-Lücke, und er wird genau zu Beginn der ersten nach der Lücke wieder aufgenommen, und das Hinzufügen von Vielfachen von 604800 ändert dann einfach die Woche. Allerdings gäbe es zusätzliche Komplikationen, z. B. was, wenn in einer Woche die letzte Stunde oder die erste Stunde fehlen würde. Vielleicht verwenden Sie iTime('USDJPY',1,X), so dass ich aus durch Minuten höchstens sind.
Oh, wow, das hat so schnell viele Beiträge ausgelöst. Nur damit es alle anderen wissen, ich denke, raptoruk ist doch in Ordnung, aber ein Haufen Beschimpfungen ist nicht willkommen, also wenn du nicht ydrol oder raptoruk bist oder jemand, der etwas Neues zu sagen hat, dann hör einfach auf zu posten, ich bin kein Troll, weil mich deine Gefühlslage so oder so nicht interessiert, und wenn du noch etwas zu sagen hast, weißt du, dass es auf taube Ohren stößt.
Ich hatte schon befürchtet, dass die Regeln für die Datentyp-Promotion so funktionieren würden. Ok, also:
datetime - datetime = long (Sekunden Dauer)
datetime +/- Sekunden(long) = datetime(ein anderes Datum)
datetime +/- Sekunden(int) = datetime(ein anderes Datum)
Aber wenn ich X=Y-Z oder (Y-Z)/60 oder etwas Ähnliches sage, wobei X bereits als long oder int deklariert ist, und Y und Z Datumszeiten sind, ist das dann sehr, sehr schlecht? Und wenn ja, würde static_cast alles in Ordnung bringen?
Raptoruk, es ist nicht zeitzonenunabhängig.
Aber was ist, wenn ich weiß, dass der Handel am Freitag um 17 Uhr Eastern Time endet, ich aber nicht weiß, in welcher Zeitzone die Zeit 0 (Mitternacht am 1. Januar 1970) liegt? Dann haben wir ein Problem, nicht wahr!
Ich hatte schon befürchtet, dass die Regeln für die Datentyp-Promotion so funktionieren würden. Ok, also:
datetime - datetime = long (Sekunden Dauer)
datetime +/- Sekunden(long) = datetime(ein anderes Datum)
datetime +/- Sekunden(int) = datetime(ein anderes Datum)
Aber wenn ich X=Y-Z oder (Y-Z)/60 oder etwas Ähnliches sage, wobei X bereits als long oder int deklariert ist und Y und Z Datumszeiten sind, ist das dann sehr, sehr schlecht? Und wenn ja, würde static_cast alles in Ordnung bringen?
Dies sind keine "Beförderungsregeln", ich bin nur vernünftig (hoffe ich!). Im Allgemeinen würde ich die oben genannten Typisierungen selbst vornehmen.
Wenn das Ergebnis meiner Berechnung immer noch eine Zahl ist, die die Sekunden seit dem 1.1.1970 angibt (unabhängig von der Zeitzone oder deren Fehlen), dann würde ich sie als datetime beibehalten.
Alles andere (eine Dauer, Minuten seit dem 1.1.1970, was auch immer) würde ich wahrscheinlich als long speichern. (Manchmal auch als int, vor allem bei typischen Dauern usw.)
Abgesehen davon ist es mir ein Rätsel, wie die Entwickler von MQL4 darauf gekommen sind, nicht UTC für alle Datetime-Daten vorzuschreiben und alle Broker zu zwingen, UTC-Daten zu senden, sondern sie einfach vom Client in Localtime interpretieren zu lassen, weil ihr derzeitiger Ansatz alles nachgelagerte unnötig verkompliziert.
Es macht die Berechnung der GMT-Zeit und der Öffnungs-/Schließungszeiten der Sitzungen während des Backtestings schwieriger als es sein sollte, wenn man es für alle Quellen von Tick-Daten korrekt machen will.
(z.B. hat Alpari mehrere Zeitzonen in seinen historischen Daten, so dass man beim Backtesting vorsichtig mit seinen Datenquellen sein muss)
PS: Habe meinen früheren Fauxpas korrigiert :)
ydrol, um alles in der Welt, was heilig ist oder was auch immer, sag mir bitte - wenn du es weißt - ob 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, machen Sie sich keine Sorgen, aber sagen Sie mir bitte, wenn Sie es wissen, wie ich Dinge in dieser Situation richtig typisieren soll.
raptoruk: "Nein ... nun, Sie vielleicht schon, ich nicht, also nein, wir nicht. Nicht für mich, nicht für Sie, nicht für uns, sondern für die Gültigkeit Ihrer früheren Aussage, dass es zeitzonenunabhängig ist. Denn es spielt keine Rolle, in welcher Zeitzone sich Ihr Broker befindet, der Devisenhandel richtet sich nicht nach der Uhr Ihres Brokers. Freitags und sonntags ist es 17 Uhr Eastern. 22 Uhr GMT. Und was ist mit der Sommerzeit/Standardzeit! Was ist damit? In einigen Ländern wird keine Stunde hinzugefügt oder abgezogen, oder die Zeit wird an einem anderen Tag umgestellt, so dass Sie am Ende mit einem Code dastehen könnten, der für einen Teil des Jahres um eine Stunde falsch ist, wenn es nicht eine nette Lösung dafür gibt. Ich habe mich noch nicht für einen Broker entschieden. Derjenige, den ich gerade ausprobiere, arbeitet mit GMT+2, aber ich glaube, dass ich ihn aufgrund seines Demokontos nicht mag. Und wenn ich ein echtes Konto ausprobiere, möchte ich vielleicht einen anderen Broker verwenden. Ich möchte also nicht, dass die Zeitzone des Brokers im Programm fest einprogrammiert ist, wenn es so einfach ist, das nicht zu tun. Seien Sie nicht schon wieder wie dieser andere Typ, der versucht, alles in eine Gelegenheit zu verwandeln, um eine Beleidigung loszuwerden, anstatt die Frage für bare Münze zu nehmen.