L1b/1: Betriebszeitzone statt Rechnerzeit - EU- und US-Instanzen sauber trennen

Wir betreiben Instanzen in zwei Regionen. Bisher hing jede Ortszeit an der
Zeitzone des Rechners (DateTime.Now, DateTimeKind.Local): derselbe Code
haette auf einem Windows-Desktop mit Europe/Berlin und in einem
Linux-Container mit UTC lautlos unterschiedliche Werte geliefert - ohne
Fehler, nur um Stunden verschoben, mitten in Buchungszeitstempeln.

AppTimeZone (Core/Time): Betriebszeitzone der Instanz, einmalig aus
Trading.ApplicationTimeZoneId gesetzt, IANA- und Windows-Schreibweise tragen
beide, unbekannter Wert weicht auf die Systemzone aus und warnt. Wird laut
Festlegung vor den ersten Trades gesetzt und danach nie gewechselt - ein
Wechsel verschoebe rueckwirkend alle Tagesgrenzen. Persistenz bleibt UTC,
damit die Daten beider Instanzen vergleichbar sind.

IbkrMapping.ParseExecutionTime verwirft die von TWS gemeldete Zeitzone nicht
mehr, sondern rechnet gegen sie nach UTC; ohne Zonenangabe gilt die
Betriebszeitzone. Das ist der Kern: eine NYSE-Ausfuehrung darf nicht mit
demselben nackten Zeitwert in die Buecher wie eine an der Eurex.
Rueckgabe ist jetzt immer Kind=Utc.

DailyReportService.NextRun -> NextRunUtc(nowUtc, hour, zone): der Bericht
laeuft zu einer festen ORTSZEIT. Sommerzeitumstellung wird behandelt - bei
der uebersprungenen Stunde weicht er aus, statt den Tag ausfallen zu lassen.

LoggingService fuehrt Anzeigezeit und UTC getrennt: Dateinamen und Anzeige in
Ortszeit (Tagesgrenzen gehoeren zur Instanz, der Supervisor liest die
JSONL-Dateien ueber diese Namen), das ts-Feld im JSONL in UTC. Beides musste
getrennt werden, weil die umgerechnete Ortszeit Kind=Unspecified traegt und
ein ToUniversalTime() darauf sie als Zeit des HOSTS gedeutet haette.

Verbleibende DateTime.Now in Worker-Zeitplaenen und Statuszeilen ebenfalls
auf AppTimeZone.Now umgestellt.

Verifiziert: 183 Tests gruen (+20), darunter EU/US-Versatz, Winter-/Sommerzeit,
unbekannte Zone und die uebersprungene Stunde bei der Zeitumstellung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/IBKRTrader.Core/Trading/Ibkr/IbkrConnection.cs

@@ -2,6 +2,7 @@ using System.Collections.Concurrent;
 using System.Globalization;
 using IBApi;
 using IBKRTrader.Core.Logging;
+using IBKRTrader.Core.Time;
 
 namespace IBKRTrader.Core.Trading.Ibkr;
 
@@ -458,7 +459,7 @@ internal sealed class IbkrConnection : DefaultEWrapper, IDisposable
         slot.Items.Add(new BrokerExecution
         {
             ExecId   = execution.ExecId,
-            Time     = IbkrMapping.ParseExecutionTime(execution.Time) ?? DateTime.MinValue,
+            Time     = IbkrMapping.ParseExecutionTime(execution.Time, AppTimeZone.Current) ?? DateTime.MinValue,
             Symbol   = contract.Symbol,
             SecType  = contract.SecType,
             Side     = IbkrMapping.ParseSide(execution.Side),

src/IBKRTrader.Core/Trading/Ibkr/IbkrMapping.cs

@@ -94,21 +94,64 @@ internal static class IbkrMapping
         side.Trim().ToUpperInvariant() is "SLD" or "SELL" ? TradeSide.Sell : TradeSide.Buy;
 
     /// <summary>
-    /// Zeitstempel einer Ausführung. TWS liefert je nach Aufruf "yyyyMMdd  HH:mm:ss" (mit doppeltem
-    /// Leerzeichen) oder zusätzlich eine Zeitzone ("20260804 17:52:56 Europe/Berlin"). Die Zeitzone
-    /// wird verworfen – der Wert bleibt Ortszeit der Börse, wie ihn TWS meldet.
+    /// Zeitstempel einer Ausführung, <b>immer als UTC</b> (<see cref="DateTimeKind.Utc"/>).
+    ///
+    /// <para>TWS liefert je nach Aufruf "20260804  17:39:18" (doppeltes Leerzeichen, ohne Zone) oder
+    /// "20260804 17:52:56 Europe/Berlin" (mit IANA-Zone) – beide Formen sind gegen das Paper-Gateway
+    /// gemessen. Ist eine Zone angegeben, wird gegen sie nach UTC gerechnet; sonst gilt
+    /// <paramref name="fallbackZone"/>, also die Betriebszeitzone der Instanz.</para>
+    ///
+    /// <para><b>Warum nicht mehr „Zone verwerfen":</b> wir betreiben Instanzen in EU und US. Würde
+    /// die gemeldete Zone weggeworfen, bekäme eine Ausführung an der NYSE denselben nackten
+    /// Zeitwert wie eine an der Eurex – und läge in den Büchern um Stunden daneben, ohne dass
+    /// irgendwo ein Fehler auftaucht.</para>
     /// </summary>
-    public static DateTime? ParseExecutionTime(string? raw)
+    /// <param name="fallbackZone">
+    /// Zeitzone für Meldungen ohne Zonenangabe – die Betriebszeitzone (<c>AppTimeZone.Current</c>).
+    /// </param>
+    public static DateTime? ParseExecutionTime(string? raw, TimeZoneInfo fallbackZone)
     {
         if (string.IsNullOrWhiteSpace(raw)) return null;
 
-        var parts = raw.Split(' ', StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries);
+        // Datum und Uhrzeit trennen TWS je nach Aufruf per Leerzeichen oder Bindestrich
+        // ("20260804-17:52:56" ist das Format, das auch der Anfragefilter nutzt).
+        var parts = raw.Replace('-', ' ')
+                       .Split(' ', StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries);
         if (parts.Length < 2) return null;
 
-        return DateTime.TryParseExact($"{parts[0]} {parts[1]}", "yyyyMMdd HH:mm:ss",
-            CultureInfo.InvariantCulture, DateTimeStyles.None, out var parsed)
-            ? parsed
-            : null;
+        if (!DateTime.TryParseExact($"{parts[0]} {parts[1]}", "yyyyMMdd HH:mm:ss",
+                CultureInfo.InvariantCulture, DateTimeStyles.None, out var local))
+            return null;
+
+        // Dritter Teil, falls vorhanden, ist die Zeitzone der Börse.
+        var zone = parts.Length >= 3 ? ResolveZone(parts[2]) ?? fallbackZone : fallbackZone;
+
+        local = DateTime.SpecifyKind(local, DateTimeKind.Unspecified);
+
+        // Bei der Zeitumstellung kann die Ortszeit ungültig (Vorstellen) oder doppelt (Zurückstellen)
+        // sein. ConvertTimeToUtc würde bei ungültigen Werten werfen – eine Ausführung darf daran
+        // nicht verlorengehen, deshalb der ausdrückliche Versatz.
+        if (zone.IsInvalidTime(local))
+            return DateTime.SpecifyKind(local - zone.BaseUtcOffset, DateTimeKind.Utc);
+
+        return TimeZoneInfo.ConvertTimeToUtc(local, zone);
+    }
+
+    /// <summary>
+    /// Löst die von TWS gemeldete Zonenangabe auf. TWS liefert IANA-Schreibweise
+    /// ("Europe/Berlin", "US/Eastern"); unter Windows braucht es dafür die Umrechnung.
+    /// Unbekannte Angabe = <c>null</c>, damit der Aufrufer auf die Betriebszeitzone ausweichen kann.
+    /// </summary>
+    private static TimeZoneInfo? ResolveZone(string id)
+    {
+        try { return TimeZoneInfo.FindSystemTimeZoneById(id); }
+        catch (TimeZoneNotFoundException) { }
+        catch (InvalidTimeZoneException)  { }
+
+        if (TimeZoneInfo.TryConvertIanaIdToWindowsId(id, out var windowsId))
+            try { return TimeZoneInfo.FindSystemTimeZoneById(windowsId!); } catch { /* unbekannt */ }
+
+        return null;
     }
 
     /// <summary>

src/IBKRTrader.Core/Trading/TradingModels.cs

@@ -111,6 +111,11 @@ public sealed record BrokerExecution
 {
     /// <summary>Eindeutige IBKR-Ausführungs-ID – geeignet als Idempotenzschlüssel beim Import.</summary>
     public required string    ExecId    { get; init; }
+    /// <summary>
+    /// Ausführungszeit in <b>UTC</b>. TWS meldet Börsen-Ortszeit (teils mit Zonenangabe); die
+    /// Umrechnung erfolgt in <c>IbkrMapping.ParseExecutionTime</c>. UTC ist Pflicht, weil wir
+    /// Instanzen in EU und US betreiben und die Daten vergleichbar bleiben müssen.
+    /// </summary>
     public required DateTime  Time      { get; init; }
     public required string    Symbol    { get; init; }
     public required string    SecType   { get; init; }