Einleitung: Warum Ihr Code mit Daten "manchmal" funktioniert?
\n\nStellen Sie sich vor: Sie schreiben eine Kalender-App oder eine Erinnerungs-App. Sie müssen einfach das aktuelle Datum nehmen und einen Tag hinzufügen. Was könnte da schon schiefgehen? Sie öffnen Stack Overflow, finden eine Frage mit tausenden Aufrufen "How do I add 1 day to an NSDate?" – und stellen fest, dass selbst eine so einfache Operation zum Albtraum werden kann.
\n\nIn diesem Artikel analysieren wir die häufigsten Fehler beim Hinzufügen eines Tages zu NSDate in Swift, lernen, sie zu vermeiden, und schreiben korrekten, zuverlässigen Code. Sie erfahren, warum der alte Ansatz mit NSDate und timeInterval der Weg zu Bugs ist und wie moderne Apple-APIs die Situation retten.
Los geht's – klären wir das Thema Daten ein für alle Mal!
\n\nFehler Nr. 1: timeInterval zum Hinzufügen eines Tages verwenden
\n\nCode-Katastrophe
\nDer häufigste "Stolperstein", auf den Anfänger treten:
\n\nlet today = NSDate()\nlet oneDay: TimeInterval = 24 * 60 * 60 // 86.400 Sekunden\nlet tomorrow = today.addingTimeInterval(oneDay)\n\nAuf den ersten Blick logisch. Ein Tag hat 24 Stunden, eine Stunde 60 Minuten, eine Minute 60 Sekunden. Multiplizieren, addieren – Profit!
\n\nAber nein. Das funktioniert nur in 99% der Fälle, und in 1% zerstört es die ganze App für die Benutzer. Warum?
\n\nFallstricke
\n- \n
- Sommer-/Winterzeitumstellung. Am Tag der Zeitumstellung kann ein Tag 23 oder 25 Stunden dauern. Ihre 86.400 Sekunden werden zu 83.400 oder 90.000. \n
- Schaltsekunden. Obwohl selten, existieren sie offiziell. \n
- Zeitzonen. Wenn der Benutzer reist, kann seine lokale Zeit durcheinandergeraten. \n
- Sekundengenauigkeit. Sie addieren nicht einfach "den nächsten Tag", sondern genau 24 Stunden – das sind unterschiedliche Dinge. \n
Ein Beispiel gefällig? Am 28. März 2021 wurden in der Ukraine die Uhren um 3:00 Uhr nachts um eine Stunde vorgestellt. Wenn Sie timeInterval zu 2:30 Uhr nachts addiert haben, erhalten Sie nicht 3:30, sondern... 4:30? Oder 2:30? Es hängt davon ab, wie das System die Umstellung verarbeitet. Kurz gesagt: Chaos.
Fehler Nr. 2: NSDate und Date in einem Projekt mischen
\n\nIn Swift gibt es zwei Datumstypen: das alte NSDate (aus Objective-C) und das moderne Date (Swift-nativ). Viele Entwickler, besonders diejenigen, die alte Tutorials oder Stack Overflow-Antworten von 2014 lesen, verwenden weiterhin NSDate.
Das Problem ist, dass NSDate eine Klasse (Referenztyp) und Date eine Struktur (Wertetyp) ist. Das Mischen im Code führt zu:
- \n
- Unklaren Bugs mit Mutabilität \n
- Überflüssigen Konvertierungen (
as Date,as NSDate) \n - Verwirrung in der API
Regel: Verwenden Sie in neuem Swift-Code ausschließlich Date. Lassen Sie NSDate für die Kompatibilität mit Objective-C-Bibliotheken.
Fehler Nr. 3: Calendar und TimeZone ignorieren
\n\nWenn Sie "1 Tag" zu einem Datum hinzufügen, tun Sie dies im Kontext eines Kalenders. Ohne Angabe eines Kalenders verwendet das System Calendar.current – den Kalender des Benutzers (normalerweise gregorianisch).
Aber was, wenn der Benutzer aus Saudi-Arabien den islamischen Kalender verwendet? Oder den japanischen? Ohne explizite Angabe des Kalenders riskieren Sie unerwartete Ergebnisse.
\n\nBeispiel für falschen Code
\nvar dateComponents = DateComponents()\ndateComponents.day = 1\nlet tomorrow = Calendar.current.date(byAdding: dateComponents, to: Date())\n\nDieser Code ist fast richtig, aber er verwendet implizit die Zeitzone des Geräts. Wenn Sie mit Serverdaten in UTC arbeiten und der Benutzer sich in Moskau (UTC+3) befindet, kann "morgen" 3 Stunden früher eintreten.
\n\nDie richtige Lösung: Calendar + DateComponents
\n\nGoldstandard zum Hinzufügen eines Tages
\nSo fügen Sie korrekt 1 Tag zu