DE
RU
EN
ES
ZH
FR
PT
AR
HI
Zeit ist eine relative Sache. Besonders im Code
Stellen Sie sich vor: Sie schreiben eine App zur Buchung von Flugtickets. Ein Benutzer aus New York wählt einen Flug um 14:00 Uhr Ortszeit, und der Server in London speichert dies als DateTime.Now. Was könnte schiefgehen? So ziemlich alles. Im besten Fall ein Ticket drei Stunden früher, im schlimmsten Fall verpasst der Benutzer den Flug und hinterlässt eine wütende Bewertung.
Das Arbeiten mit Zeitzonen in C# ist ein Thema, das viele Entwickler auf "später" verschieben. Aber genau das trennt Amateur-Code von professionellem Code. Heute werden wir uns ansehen, wie Sie Ihre Anwendung mit Zeitzonen befreunden, ohne an der Sommerzeit verrückt zu werden und ohne einen einzigen Benutzer zu verlieren.
DateTime vs DateTimeOffset: Erster Kampf mit der Realität
Viele Anfänger in C# verwenden DateTime für alles. Und das ist in Ordnung, solange Sie nicht mit globalen Benutzern zu tun haben. Das Problem ist, dass DateTime an sich nicht weiß, in welcher Zeitzone es sich befindet. Es ist einfach ein "Moment in der Zeit" ohne Kontext.
// Schlecht: Zeit ohne KontextDateTime localTime = DateTime.Now; // 14:00 – aber wo?DateTime utcTime = DateTime.UtcNow; // schon besser, aber immer noch nicht ideal
// Gut: Zeit mit OffsetDateTimeOffset withOffset = DateTimeOffset.Now; // 14:00 +03:00Console.WriteLine(withOffset); // 06.04.2025 14:00:00 +03:00DateTimeOffset ist Ihr erster Schritt zu einem bewussten Zeitmanagement. Es speichert nicht nur Datum und Uhrzeit, sondern auch den Offset relativ zur UTC. Das hilft, wenn Sie Daten zwischen Systemen übertragen oder dem Benutzer einfach die korrekte lokale Zeit anzeigen möchten.
Wann wird DateTime dennoch benötigt?
Ehrlich? Fast nie zum Speichern von Zeitpunkten. Wenn Sie Code für eine lokale Desktop-Anwendung schreiben – okay. Aber sobald eine Datenbank, API oder mehrere Benutzer ins Spiel kommen, wechseln Sie zu DateTimeOffset oder DateTime mit expliziter Angabe von DateTimeKind.Utc.
TimeZoneInfo: Ihr persönlicher Zeitzonenatlas
In .NET gibt es die mächtige Klasse TimeZoneInfo. Sie ermöglicht die Arbeit mit allen Zeitzonen, die dem Betriebssystem bekannt sind. Und es gibt hunderte – von den Standard-UTC+0 bis zu exotischen Zonen wie "Lord Howe Island" mit einem 30-Minuten-Offset.
// Liste aller verfügbaren Zonen abrufenReadOnlyCollection<TimeZoneInfo> allZones = TimeZoneInfo.GetSystemTimeZones();foreach (var zone in allZones.Take(5)){ Console.WriteLine($"{zone.Id}: {zone.DisplayName}");}// Ausgabe (Beispiel):// UTC: (UTC) Coordinated Universal Time// Russian Standard Time: (UTC+03:00) Moscow, St. Petersburg// Eastern Standard Time: (UTC-05:00) Eastern Time (US & Canada)Zeitkonvertierung zwischen Zonen
Angenommen, ein Benutzer aus Moskau möchte wissen, wann ein Webinar nach Londoner Zeit beginnt. So machen Sie es richtig:
// Ursprungszeit – Moskauer ZeitDateTime moscowTime = new DateTime(2025, 6, 15, 18, 0, 0);TimeZoneInfo moscowZone = TimeZoneInfo.FindSystemTimeZoneById("Russian Standard Time");TimeZoneInfo londonZone = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
// KonvertierungDateTime londonTime = TimeZoneInfo.ConvertTime(moscowTime, moscowZone, londonZone);Console.WriteLine($"In Moskau: {moscowTime}, in London: {londonTime}");// In Moskau: 15.06.2025 18:00:00, in London: 15.06.2025 16:00:00Beachten Sie: Wir geben explizit die Quell- und Zielzone an. Das schließt Mehrdeutigkeiten aus. TimeZoneInfo.ConvertTime berücksichtigt automatisch die Zeitdifferenz, einschließlich Sommer-/Winterzeit.
Sommerzeit (DST): Der größte Feind des Entwicklers
Zweimal im Jahr dreht die Welt durch. Im März werden die Uhren vorgestellt, im Oktober zurück. Und wenn Ihre Anwendung nicht auf DST vorbereitet ist, sehen die Benutzer entweder eine "zusätzliche" Stunde oder eine verpasste. C# bewältigt dies autom
