Interne Variable weich vom Chart-OHLC derselben geschlossenen Kerze ab

Lili HR · 2026-10-02T10:18:21+00:00

Ich habe einen benutzerdefinierten ProScreener (ProBuilder), der ca. 33 Instrumente in Echtzeit auswertet, implementiert in zwei unabhängigen Skripten, die dieselbe Logik zur Berechnung der Zeitfenster-Spanne (Range) verwenden. Am 02.10.2026 änderte sich für den DAX eine interne Variable meines Codes (die den höchsten innerhalb eines festen Zeitfensters erreichten Kurs speichert, 00:00–08:59 MESZ plus eine einzige erlaubte Verlängerung bis 09:05) auf der Kerze von 09:00:00–09:05:00 MESZ. Mein Kerzenchart (5-Minuten-Timeframe) zeigt für genau diese Kerze ein Hoch von 25.012,1 — niedriger als der Wert, den mein Code bereits vor 09:00 Uhr akkumuliert hatte (25.063,9). Meine Logik (IF high > CajaMax THEN CajaMax = high) hätte diesen Wert also gar nicht ändern dürfen. Trotzdem erfasste mein Skript als Endwert 25.111 — eine Differenz von 99 Punkten gegenüber dem im Chart angezeigten Hoch dieser Kerze. Fast zwei Stunden später (10:53 MESZ) hatte sich dieselbe interne Variable erneut geändert, diesmal auf 25.143,9 — ein dritter, abweichender Wert, weit außerhalb jedes Zeitfensters, das meine Logik zur Berechnung dieser Spanne verwendet. Ich konnte dies zum selben Zeitpunkt identisch in meinen zwei unabhängigen Skripten bestätigen, was einen eigenen Programmierfehler ausschließt und auf ein Problem an der Datenquelle hindeutet. Soweit ich weiß, führt ProScreener den gesamten Code nach Abschluss jedes Scan-Zyklus über das gesamte Instrumenten-Universum erneut von der ersten Kerze an aus. Könnte eine verspätete Korrektur/Konsolidierung einer bereits “geschlossenen” Kerze durch den Datenfeed erklären, dass sich meine akkumulierte Variable bei späteren Neuberechnungen ändert, Stunden nach dieser Kerze? Ich habe dasselbe Muster (eine Bereichsgrenze mit einem Wert, der nicht dem Chart entspricht) bei anderen Instrumenten (CL, GBPUSD) in früheren Sitzungen reproduziert. Plattformversion: [bitte ergänzen] Kontotyp / Datenfeed: [bitte ergänzen] Instrument / genaues Ticker-Symbol: DAX, [genauen Code ergänzen] Chart-Timeframe: 5 Minuten ProScreener-Timeframe: [bitte ergänzen] Eingestellte Zeitzone: MESZ (UTC+2) Datum der Reproduktion: 02.10.2026 Beobachtete Werte (DAX): – Reales Box-Hoch (Chart, Box-Indikator): 25.063,9 – Hoch der Kerze 09:00–09:05 (Chart): 25.012,1 – Intern erfasster Wert (~09:00–09:55): 25.111 – Später intern erfasster Wert (10:53 MESZ, gleicher Tag): 25.143,9 Ich kann bei Bedarf den relevanten Code-Ausschnitt (nur Box-Konstruktion, ohne die proprietäre Trading-/Scoring-Logik) sowie Screenshots von Chart und Screener-Ausgabe für diesen Fall nachreichen.

Viewing 10 posts - 1 through 10 (of 10 total)

Author

Posts
10/02/2026 at 12:18 PM #265451 quote

Lili HR
Participant

Junior

Ich habe einen benutzerdefinierten ProScreener (ProBuilder), der ca. 33 Instrumente in Echtzeit auswertet, implementiert in zwei unabhängigen Skripten, die dieselbe Logik zur Berechnung der Zeitfenster-Spanne (Range) verwenden. Am 02.10.2026 änderte sich für den DAX eine interne Variable meines Codes (die den höchsten innerhalb eines festen Zeitfensters erreichten Kurs speichert, 00:00–08:59 MESZ plus eine einzige erlaubte Verlängerung bis 09:05) auf der Kerze von 09:00:00–09:05:00 MESZ. Mein Kerzenchart (5-Minuten-Timeframe) zeigt für genau diese Kerze ein Hoch von 25.012,1 — niedriger als der Wert, den mein Code bereits vor 09:00 Uhr akkumuliert hatte (25.063,9). Meine Logik (IF high > CajaMax THEN CajaMax = high) hätte diesen Wert also gar nicht ändern dürfen. Trotzdem erfasste mein Skript als Endwert 25.111 — eine Differenz von 99 Punkten gegenüber dem im Chart angezeigten Hoch dieser Kerze. Fast zwei Stunden später (10:53 MESZ) hatte sich dieselbe interne Variable erneut geändert, diesmal auf 25.143,9 — ein dritter, abweichender Wert, weit außerhalb jedes Zeitfensters, das meine Logik zur Berechnung dieser Spanne verwendet. Ich konnte dies zum selben Zeitpunkt identisch in meinen zwei unabhängigen Skripten bestätigen, was einen eigenen Programmierfehler ausschließt und auf ein Problem an der Datenquelle hindeutet. Soweit ich weiß, führt ProScreener den gesamten Code nach Abschluss jedes Scan-Zyklus über das gesamte Instrumenten-Universum erneut von der ersten Kerze an aus. Könnte eine verspätete Korrektur/Konsolidierung einer bereits “geschlossenen” Kerze durch den Datenfeed erklären, dass sich meine akkumulierte Variable bei späteren Neuberechnungen ändert, Stunden nach dieser Kerze? Ich habe dasselbe Muster (eine Bereichsgrenze mit einem Wert, der nicht dem Chart entspricht) bei anderen Instrumenten (CL, GBPUSD) in früheren Sitzungen reproduziert. Plattformversion: [bitte ergänzen] Kontotyp / Datenfeed: [bitte ergänzen] Instrument / genaues Ticker-Symbol: DAX, [genauen Code ergänzen] Chart-Timeframe: 5 Minuten ProScreener-Timeframe: [bitte ergänzen] Eingestellte Zeitzone: MESZ (UTC+2) Datum der Reproduktion: 02.10.2026 Beobachtete Werte (DAX): – Reales Box-Hoch (Chart, Box-Indikator): 25.063,9 – Hoch der Kerze 09:00–09:05 (Chart): 25.012,1 – Intern erfasster Wert (~09:00–09:55): 25.111 – Später intern erfasster Wert (10:53 MESZ, gleicher Tag): 25.143,9 Ich kann bei Bedarf den relevanten Code-Ausschnitt (nur Box-Konstruktion, ohne die proprietäre Trading-/Scoring-Logik) sowie Screenshots von Chart und Screener-Ausgabe für diesen Fall nachreichen.

Captura-de-pantalla-2026-10-02-a-las-12.17.58-scaled.png

10/02/2026 at 12:27 PM #265452 quote
Lili HR
Participant

Junior
Anbei der relevante Codeausschnitt (nur Berechnung der Sitzungsspanne/Box, ohne die eigentliche Handelslogik), der das in der Anfrage beschriebene Verhalten reproduziert. CajaMax/CajaMin entsprechen den im Text genannten internen Werten; UltimaExtCaja ist eine zusätzlich eingebaute Diagnosevariable, die die Uhrzeit der letzten Änderung von CajaMax/CajaMin speichert.
```
// ============================================================
// Codeausschnitt zur Fehlermeldung an ProRealTime-Support
// DAX, Sitzung 02.10.2026 — Berechnung der Sitzungsspanne (Box)
// ------------------------------------------------------------
// Auszug OHNE die eigentliche Handels-/Scoring-Logik (Entry, SL,
// TP1/TP2, Filter, Score-Gewichtung usw.) — nur der Teil, der die
// Variablen CajaMax/CajaMin (Session-Hoch/-Tief) berechnet und der
// im gemeldeten Fall das beschriebene Verhalten zeigt. Identisch in
// den zwei unabhaengigen Skripten, die denselben Fehler zeigen.
// ============================================================

// --- Sommerzeit-Berechnung (Europe/Berlin, automatisch) ---
aDay        = date MOD 100
aMonth      = (date MOD 10000 - date MOD 100) / 100
aDayOfWeek  = DayOfWeek
IF aDayOfWeek = 7 THEN
aDayOfWeek0Dom = 0
ELSE
aDayOfWeek0Dom = aDayOfWeek
ENDIF
aLastSunDay = aDay - aDayOfWeek0Dom
IF aMonth >= 4 AND aMonth <= 9 THEN
aAutoDST = 1
ELSIF aMonth = 3 THEN
IF aLastSunDay >= 25 THEN
aAutoDST = 1
ELSE
aAutoDST = 0
ENDIF
ELSIF aMonth = 10 THEN
IF aLastSunDay >= 25 THEN
aAutoDST = 0
ELSE
aAutoDST = 1
ENDIF
ELSE
aAutoDST = 0
ENDIF
IF aAutoDST = 1 THEN
berlinOffset = 2
ELSE
berlinOffset = 1
ENDIF

utcStartHour  = 0
utcEndHour    = 7
HoraInicioBox = (utcStartHour + berlinOffset) * 10000
HoraFinBox    = (utcEndHour + berlinOffset) * 10000 - 100

// --- Erkennung Sitzungswechsel (taeglicher Reset um 00:00 CET/CEST) ---
NewSessionCET = (time < time[1]) OR (DayOfWeek <> DayOfWeek[1] AND DayOfWeek[1] = 5)

// --- Initialisierung / Carry-forward, jede Kerze ---
CajaMax       = CajaMax[1]
CajaMin       = CajaMin[1]
inBox         = inBox[1]
// Diagnosevariable (read-only, nur zur Fehlersuche hinzugefuegt):
// speichert die Uhrzeit (HHMMSS) der letzten Aenderung von CajaMax/CajaMin.
UltimaExtCaja = UltimaExtCaja[1]

// --- Taeglicher Reset ---
IF NewSessionCET THEN
CajaMax       = 0
CajaMin       = 0
UltimaExtCaja = 0
ENDIF

// --- Aufbau der Sitzungsspanne (00:00-08:59 CEST im gemeldeten Fall) ---
IF time > HoraInicioBox AND time <= HoraFinBox THEN
IF NewSessionCET OR inBox = 0 THEN
CajaMax = high
CajaMin = low
inBox   = 1
UltimaExtCaja = time
ELSE
IF high > CajaMax THEN
CajaMax = high
UltimaExtCaja = time
ENDIF
IF low < CajaMin THEN
CajaMin = low
UltimaExtCaja = time
ENDIF
ENDIF
ELSE
inBox = 0
ENDIF

// --- Einzige erlaubte Verlaengerung: die eine Kerze, die HoraFinBox kreuzt ---
IF time > HoraFinBox AND time[1] <= HoraFinBox THEN
IF CajaMax > 0 AND CajaMin > 0 THEN
IF high > CajaMax THEN
CajaMax = high
UltimaExtCaja = time
ENDIF
IF low < CajaMin THEN
CajaMin = low
UltimaExtCaja = time
ENDIF
ENDIF
ENDIF

// ------------------------------------------------------------
// Am Ende des Skripts (ProScreener-Ausgabe) werden u.a. folgende
// Werte angezeigt, auf die sich die Fehlermeldung bezieht:
//   CajaMax, CajaMin        -> interner Session-Hoch/-Tief-Wert
//   UltimaExtCaja           -> Uhrzeit der letzten Aenderung (Diagnose)
//
// Beobachtete Werte fuer DAX, 02.10.2026:
//   Reales Box-Hoch (Chart):                 25.063,9
//   Hoch der Kerze 09:00-09:05 (Chart):      25.012,1
//   CajaMax, erstmals beobachtet (~09:xx):   25.111
//   CajaMax, spaeter beobachtet (10:53 CEST):25.143,9
//   UltimaExtCaja zeigte in beiden Faellen:  09:00:00
// -----------------------------------------------------------
```
10/02/2026 at 6:53 PM #265453 quote
robertogozzi
Moderator

Legend
In der ProRealTime-Sprache sind diese Anweisungen:
```
CajaMax    = CajaMax[1]

CajaMin    = CajaMin[1]

inBox     = inBox[1]

UltimaExtCaja = UltimaExtCaja[1]
```
überflüssig, da ALLE Variablen mit demselben Wert, den sie in der vorherigen Kerze hatten, in die neue Kerze übernommen werden.
Die Verwendung von [1] für den Zugriff auf den Wert der vorherigen Kerze ist also nur dann sinnvoll, wenn dieser Wert in der Zwischenzeit geändert wurde.
Das dient allerdings nur der Dokumentation; es ist mit Sicherheit nicht die Ursache für dein Problem.
Warum fragst du nicht die KI?
Ich weiß nicht, ob dir diese hier weiterhelfen kann:
https://ai.prorealcode.com/
ansonsten kannst du es mit ChatGPT, Gemini, Copilot usw. versuchen.

Iván González thanked this post
10/02/2026 at 10:35 PM #265454 quote
Lili HR
Participant

Junior
Danke für den Hinweis zu den [1]-Zeilen — verstanden, das ist nur Dokumentation und sicher nicht die Ursache.
Bevor ich die eigentliche Frage wiederhole, die naheliegenden Alternativerklärungen habe ich bereits geprüft und ausgeschlossen:
- Alle betroffenen Scripts/Instrumente laufen auf demselben Timeframe (M5) — kein Timeframe-Unterschied zwischen ProScreener und Chart.
- Das Problem tritt auch bei Instrumenten auf, die eindeutig nur einem Symbol/Feed zugeordnet sind — kein Symbol-Mapping- oder Feed-Unterschied.
- Die Sitzungserkennung in meinem Code basiert ausschließlich auf time/DayOfWeek der jeweiligen Kerze, nicht auf deren Position innerhalb der ProScreener-Rekonstruktion.
- Laut Handbuch verarbeitet ProScreener maximal die letzten 256 Kerzen (1.024 auf Premium-Plattformen) — bei M5 deckt das aber meine komplette Sitzung plus mehrere Stunden danach ab, das erklärt die Größenordnung meines Falls nicht.
Ich habe die Frage zusätzlich mit Perplexity, ChatGPT und der ProRealCode-KI (ai.prorealcode.com) geprüft, wie vorgeschlagen. Keine davon konnte eine offizielle Dokumentation oder einen Forenbeitrag mit Moderator-Bestätigung finden, die bestätigt, dass der High/Low-Wert einer bereits abgeschlossenen Kerze sich zwischen zwei ProScreener-Zyklen ändern kann — alle drei stufen das explizit als “nicht bestätigt” ein, nicht als widerlegt.
Die eigentliche Frage bleibt also: Kann der High/Low-Wert einer bereits abgeschlossenen Kerze zwischen zwei vollständigen ProScreener-Zyklen (für dasselbe Instrument, Konto, Feed und Timeframe) unterschiedlich ausfallen? In meinem Fall änderte sich mein akkumulierter Session-Höchstwert für den DAX zwischen 09:00 und 10:53 Uhr gleich zweimal (25.111 → 25.143,9), obwohl die betroffene Kerze laut Chart (Hoch 25.012,1) diese Änderung logisch nicht hätte auslösen dürfen — und das bei einer Kerze, die zu diesem Zeitpunkt längst abgeschlossen war.
Gibt es einen dokumentierten Mechanismus (späte Datenkorrektur/-konsolidierung des Feeds für eine bereits geschlossene Kerze, oder etwas anderes), der das erklären könnte?
10/03/2026 at 7:29 PM #265458 quote

robertogozzi
Moderator

Legend

Jeder Wert kann sich innerhalb derselben Kerze ändern, wenn der Screener während ihrer Laufzeit (z. B. 1 Sekunde, 1 Minute usw.) mehrfach ausgeführt wird (stets im Live-Modus); tatsächlich sollten Screener sehr häufig – idealerweise bei jedem Tick – ausgeführt werden, sofern die Servergeschwindigkeit dies zulässt.
Wenn du hingegen einen festen Wert benötigst, musst du dich auf die zuletzt abgeschlossene Kerze beziehen – nicht auf die aktuelle – und für den gewünschten Datenpunkt den Index [1] verwenden.

10/05/2026 at 7:38 AM #265472 quote

JS
Participant

Master

Hallo,
wenn ich den DAX-Chart zum Vergleich heranziehe, sehe ich einige Unterschiede zu der Beschreibung, die du gibst…
Am Freitag, den 2. Oktober, DAX M5 (UTC+2), liegt das High der Kerze von 09:00–09:05 bei 25.012,1. Das höchste High bis zu diesem Zeitpunkt liegt bei 25.063,9. Das stimmt vollständig mit deiner Beschreibung überein…
Danach schreibst du, dass die interne Variable fast zwei Stunden später, um 10:53 CEST, den Wert 25.143,9 anzeigt…
Genau hier gibt es jedoch eine Abweichung zu meinem Chart: In meinem Chart erscheint der Wert 25.143,9 bereits bei der Kerze von 09:50–09:55 CEST. Die Zeitangaben laufen also auseinander. Was du als „fast zwei Stunden später“ beschreibst, erscheint in meinem Chart bereits innerhalb derselben Stunde.
Mein Verdacht ist deshalb, dass irgendwo etwas mit dem „BerlinOffset“ nicht stimmt. Damit verbunden ist für mich auch das ziemlich frustrierende Problem, herauszufinden, in welcher Zeitzone „time“ innerhalb des ProScreener tatsächlich verwendet wird. Ich habe das bisher nie zuverlässig nachvollziehen können…
Könnte es sein, dass hier eine unterschiedliche Zeitzone bzw. eine falsche Berechnung des BerlinOffset dazu führt, dass die Zeitstempel im ProScreener und im Chart nicht übereinstimmen?

Nicolas, Iván González, robertogozzi and RAM24 thanked this post

Schermafbeelding-2026-10-05-om-07.36.55.png Schermafbeelding-2026-10-05-om-07.37.15.png

10/05/2026 at 7:47 AM #265474 quote

JS
Participant

Master

09:00-09:05 (UTC+2)

Schermafbeelding-2026-10-05-om-07.45.00.png

10/07/2026 at 11:08 AM #265519 quote
RAM24
Participant

Average
Hallo robertogozzi,
danke nochmal für deine Erklärung zur Live-Neubewertung von Kerzen im ProScreener. Wir haben den vorgeschlagenen Fix umgesetzt — die Box-Berechnung liest seitdem High[1]/Low[1]/Time[1] (letzte abgeschlossene Kerze) statt high/low/time (laufende Kerze).
Leider hat das Problem nicht gelöst, nur verschoben. Wir haben beide Varianten parallel über mehrere Handelstage mit echten Instrumenten verglichen (ProScreener-interne CajaMax/CajaMin gegen die reale Box, die ein separater, auf demselben Chart laufender Indikator anhand derselben Kerzen zeichnet):
- Mit High[1]/Low[1] (abgeschlossene Kerze): Abweichungen von 29 bis 69 Punkten je nach Instrument und Tag, mal auf der CajaMax-, mal auf der CajaMin-Seite.
- Mit high/low (laufende Kerze, Originalzustand): Abweichungen von 3 bis 44 Punkten, ebenfalls unregelmäßig verteilt.
Das deutlichste Beispiel von heute (EURUSD, 5-Minuten-Zeitrahmen, mit der High[1]/Low[1]-Variante aktiv): Die reale Box lag bei HIGH=1,12543 / LOW=1,12221. Der ProScreener berechnete intern CajaMin=1,11823 — 39,8 Pips zu niedrig. Der reale Ausbruch (Short) wurde vom separaten Chart-Indikator sauber erkannt und lag zum Zeitpunkt der Prüfung bereits bei +0,7R Gewinn. Der ProScreener zeigte dagegen State=0 — keine Ruptur erkannt —, weil der Kurs seine eigene (zu niedrige) CajaMin-Schwelle schlicht noch nicht unterschritten hatte.
Auffällig: Dasselbe Instrument (EURUSD) war an einem anderen Handelstag, mit derselben Codeversion, exakt korrekt (CajaMin traf den realen Wert auf den Pip genau). Das Problem ist also weder instrumentspezifisch noch abhängig davon, welche Kerze gelesen wird — es tritt unregelmäßig auf, mal stärker, mal gar nicht.
Daraus unsere Vermutung, die wir aber nicht verifizieren können: Könnte es sein, dass der Feed Kursdaten für eine Kerze, die der ProScreener bereits als “abgeschlossen” behandelt (egal ob laufende oder vorherige Kerze), nachträglich korrigiert — nachdem CajaMax/CajaMin aus dieser Kerze bereits fixiert wurden? Das würde erklären, warum weder high/low noch High[1]/Low[1] zuverlässig sind, da beide auf Daten basieren, die der Feed später noch revidieren kann.
Gibt es in ProBuilder/ProRealTime eine Möglichkeit, so eine nachträgliche Korrektur zu erkennen — zum Beispiel eine Funktion, die bestätigt, dass für eine bestimmte historische Kerze keine weiteren Revisionen mehr folgen? Oder kennst du einen anderen Mechanismus, der erklären könnte, warum ein in ProBuilder berechneter Kerzen-Höchst-/Tiefstwert dauerhaft und deutlich vom realen Chart abweicht, obwohl die Formel nachweislich korrekt ist und bereits abgeschlossene Kerzen verwendet?
Danke dir schon mal für jeden Hinweis.

Captura-de-pantalla-2026-10-07-a-las-11.07.51-scaled.png
10/07/2026 at 6:33 PM #265525 quote

robertogozzi
Moderator

Legend

Ich kann das nicht einsehen; ich glaube, nur IG oder ProRealTime können verlässliche Analysen der Kerzen durchführen und überprüfen, ob diese nach der Schließung verändert wurden.
Ich empfehle dir, in der Plattform die Tastenkombination Strg+M (Ctrl+M) zu drücken, um eine Support-Anfrage zu stellen.

10/08/2026 at 2:29 PM #265537 quote
Nicolas
Keymaster

Legend
Hallo Lili,

ich habe mir den Thread und deinen Code angesehen. Ich kann das Problem nicht abschließend bestätigen, sehe aber zwei Punkte, die ich vor einem Support-Ticket prüfen würde. Dass der Feed Kerzen nachträglich korrigiert, sehe ich im Thread nicht belegt.

1. TIME ist die Schlusszeit der Kerze

In ProBuilder liefert TIME die Schlusszeit der Kerze, nicht die Öffnungszeit (OPENTIME). Eine M5-Kerze mit der Beschriftung 08:55 hat also time = 090000. Deine “einzige erlaubte Verlängerung” bei time = 09:00:00 ist daher die Kerze 08:55-09:00 und nicht die Kerze 09:00-09:05, mit der du sie vergleichst.

2. Mögliche Zeitverschiebung zwischen Screener und Chart

JS hat in seinem Chart gesehen, dass 25.143,9 schon in der Kerze 09:50-09:55 CEST auftaucht, nicht erst um 10:53. Dazu passt, dass deine Diagnosevariable UltimaExtCaja bei beiden Werten auf 09:00:00 steht, obwohl sich CajaMax geändert hat. Eine wirklich abgeschlossene Kerze kann ihr Hoch nicht ändern. Wenn aber die time-Werte im Screener gegenüber dem Chart um eine Stunde versetzt sind (z. B. CET statt CEST), baut sich deine Box in Wirklichkeit bis ca. 10:00 CEST auf. Sie würde dann die Stunde 09:00-10:00 CEST mit der Londoner Eröffnung aufnehmen.

Das würde einiges erklären: Die Abweichung tritt nur an Tagen auf, an denen diese zusätzliche Stunde neue Extremwerte bringt, also unregelmäßig. Ein echter Ausbruch kann so in der Box “verschwinden”, wie bei deinem EURUSD-Beispiel. Und der Wechsel auf High[1]/Low[1] ändert nichts, weil das Zeitfenster falsch liegt und nicht die gelesene Kerze. Ob das bei dir zutrifft, kann ich ohne deine Daten nicht sagen.

3. Datenquelle: Chart und Screener sind nicht unbedingt identisch

Der ProScreener arbeitet mit den offiziellen Marktdaten des Instruments, nicht mit individuell angepassten Chart-Daten. Falls dein Chart bzw. dein Box-Indikator mit einer eigenen Konfiguration läuft (andere Zeitzone, angepasste Handelszeiten/Session, andere Datenquelle oder Einstellungen), sind Abweichungen zwischen Chart-Indikator und Screener möglich, auch bei identischer Formel. Bitte prüfe, ob der Chart, mit dem du vergleichst, dieselben Daten und dieselbe Zeitzone verwendet wie der Screener.

Test

Lass dir im Screener und im Chart für dieselbe Kerze time, OpenTime und Timestamp MOD 86400 ausgeben und vergleiche die Werte. Wenn sie um eine Stunde abweichen, ist die Ursache gefunden.

Möglicher Ansatz ohne Sommerzeit-Berechnung

Timestamp ist ein Unix-Zeitstempel der Kerzenschlusszeit und damit unabhängig von Zeitzone und Sommerzeit. Damit lässt sich die Box direkt in UTC definieren (ungetestet, bitte selbst prüfen):
```
utcSek = Timestamp MOD 86400
// Box 00:00-07:00 UTC, bezogen auf die Schlusszeit der Kerze
IF utcSek > 0 AND utcSek <= 25200 THEN
   // Box aufbauen
ENDIF
```
Dann entfallen berlinOffset und die gesamte DST-Logik.

Falls der Test eine Verschiebung zeigt, hat sich das Support-Ticket bei ProRealTime erledigt. Ansonsten ist ihre Antwort zur Datenkorrektur durch den Feed die richtige Auskunft.

robertogozzi thanked this post
Author

Posts