Beim Abrufen von Daten für einen ausgewählten Datumsbereich stellten wir fest, dass unsere Berechnung etwas daneben lag. Als wir jedoch das Datum um einen Tag verkürzten, stimmten die Daten genau überein!

Hmmm… Möglicherweise liegt ein Problem mit der Handhabung des Datums in unserem Code vor. Möglicherweise wird die Zeitzone nicht richtig gehandhabt – und ja, ich hatte recht!

Beim Erstellen von Anwendungen, an denen Benutzer aus verschiedenen Zeitzonen beteiligt sind, kann der ordnungsgemäße Umgang mit Datumsangaben schwierig sein. Das Speichern von Datumsangaben in UTC ist eine gängige Best Practice zur Gewährleistung der Konsistenz, aber die Dinge können kompliziert werden, wenn Benutzer Datumsangaben in ihrer lokalen Zeitzone eingeben, insbesondere beim Filtern und Abfragen.

Entwickler greifen häufig auf das native JavaScript-Datumsobjekt zurück, um diese Konvertierungen durchzuführen. Dieser Ansatz kann jedoch zu Inkonsistenzen zwischen Umgebungen führen, beispielsweise zwischen Node.js und Browserkonsolen wie Chrome. In diesem Artikel untersuchen wir, warum die ordnungsgemäße Handhabung von Datums- und Zeitzonenkonvertierungen von entscheidender Bedeutung ist, wie Luxon diesen Prozess vereinfachen kann und warum die Verwendung des nativen JavaScript-Datumsobjekts zu Inkonsistenzen führen kann.

Das Problem: UTC-Speicherung vs. lokale Zeitfilterung

Wenn Daten in UTC gespeichert werden, stellen sie einen globalen Standard dar, der die durch Zeitzonen verursachte Mehrdeutigkeit beseitigt. Allerdings denken Benutzer typischerweise in Bezug auf ihre lokale Zeitzone. Diese Diskrepanz wird deutlich, wenn Benutzer versuchen, Datensätze mithilfe lokaler Zeiteingaben nach Datum zu filtern.

Sehen wir uns ein Beispiel an, bei dem die Ortszeiteingaben eines Benutzers zu fehlenden Datensätzen führen können, wenn sie nicht ordnungsgemäß behandelt werden.

Beispielszenario: Ein Benutzer in der Zeitzone GMT-7

Stellen Sie sich einen Benutzer in der GMT-7-Zeitzone (pazifische Sommerzeit) vor. Am 5. September 2024 erstellen sie um 22:00 Uhr in ihrer Ortszeit einen Datensatz. Das passiert hinter den Kulissen:

• 5. September 2024, 22:00 Uhr GMT-7 wird in 6. September 2024, 05:00 Uhr UTC konvertiert und als solche in der Datenbank gespeichert.
• Der Benutzer nimmt jedoch wahr, dass er diesen Datensatz am 5. September erstellt hat.

Die Filterinkongruenz

Angenommen, der Benutzer möchte alle am 5. September erstellten Datensätze abfragen. Sie geben das Datum 5. September 2024 ein und erwarten, ihren Datensatz abzurufen. Wenn das System jedoch das Eingabedatum direkt mit dem gespeicherten Datum UTC vergleicht, ohne Zeitzonenunterschiede anzupassen, wird der Benutzer den Datensatz übersehen. Warum?

• Der Datensatz wurde in der Datenbank als 6. September (UTC) gespeichert.
• Der Benutzer filtert nach dem 5. September (seiner Ortszeit), aber das System vergleicht dies mit UTC, was zu keiner Übereinstimmung führt.

JavaScript-Datumsobjekt: Inkonsistenzen zwischen Umgebungen

Der folgende Beispielcode zeigt ein häufiges Problem bei der Verwendung des nativen JavaScript-Date-Objekts zur Verarbeitung von Datums- und Uhrzeitkonvertierungen, insbesondere in verschiedenen Umgebungen wie Node.js und dem Browser (z. B. Chrome-Konsole).

Beispielcode:

function convertToUtcStartOfDay(isoString) {
  // Step 1: Parse the ISO string into a Date object
  let localDate = new Date(isoString);

  // Step 2: Set the time to the start of the day (00:00:00) in local time zone
  localDate.setHours(0, 0, 0, 0);

  // Step 3: Get the UTC time using toISOString() – it converts local time to UTC
  let utcStartOfDay = localDate.toISOString();

  return utcStartOfDay; // This will be in UTC
}

// Example usage:
let frontendDate = "2023-08-22T00:00:00 05:30"; // ISO string with timezone offset
let startOfDayUtc = convertToUtcStartOfDay(frontendDate);

console.log(startOfDayUtc); // Expected output: "2023-08-21T18:30:00.000Z"

In diesem Beispiel gibt der Benutzer das Datum „2023-08-22T00:00:00 05:30“ ein (aus einer Zeitzone GMT 5:30). Das Date-Objekt sollte es in den Beginn des Tages in UTC umwandeln, aber wenn es ausgeführt wird:

• In Node.js lautet die Ausgabe 2023-08-21T00:00:00.000Z – Falsch
• In der Chrome-Konsole lautet die Ausgabe 2023-08-21T18:30:00.000Z – Richtig

Diese Diskrepanz kann je nachdem, wo der Code ausgeführt wird, zu unvorhersehbaren Ergebnissen führen. Dieses Verhalten macht das Date-Objekt für eine konsistente Datumsverarbeitung in verschiedenen Umgebungen unzuverlässig.

Verwendung von Luxon für die genaue Datenverarbeitung

Um dieses Problem zu lösen, ist es wichtig, eine Bibliothek wie Luxon zu verwenden, die konsistentes Verhalten in allen Umgebungen bietet. Luxon hilft Ihnen, die lokalen Eingaben des Benutzers in den richtigen Start und Ende des Tages in seiner Zeitzone umzuwandeln und diese Zeiten dann für genaue Datenbankabfragen in UTC umzuwandeln.

Hier ist ein Beispiel mit Luxon, um dies zu handhaben:

const { DateTime } = require('luxon');

// Example user input date in ISO string with timezone information from the frontend
const userInputDate = "2023-08-22T00:00:00 05:30"; // ISO string sent by frontend

// Step 1: Parse the ISO string to get the user's local time
const userLocalDate = DateTime.fromISO(userInputDate);

// Step 2: Convert this date to start of the day and end of the day in the user's local timezone
const startOfDayLocal = userLocalDate.startOf('day'); // start of the day in the user's timezone
const endOfDayLocal = userLocalDate.endOf('day'); // end of the day in the user's timezone

// Step 3: Convert these local start and end times to UTC
const startOfDayUtc = startOfDayLocal.toUTC().toJSDate(); // start of the day in UTC
const endOfDayUtc = endOfDayLocal.toUTC().toJSDate(); // end of the day in UTC

// Step 4: Query the database using the UTC range
db.records.find({
  createdAt: {
    $gte: startOfDayUtc,
    $lte: endOfDayUtc
  }
});

Warum Luxon besser ist als JavaScript-Datumsobjekte

Die direkte Verarbeitung von Datums- und Zeitzonenkonvertierungen mit dem nativen JavaScript-Datumsobjekt kann zu Inkonsistenzen wie der oben gezeigten führen. Hier sind einige Gründe, warum Luxon eine bessere Alternative ist:

1. Konsistenz über Umgebungen hinweg: Luxon bietet konsistentes Verhalten, unabhängig davon, ob der Code in Node.js oder im Browser (z. B. Chrome-Konsole) ausgeführt wird. Dadurch werden die Diskrepanzen beseitigt, die durch die Verwendung des Date-Objekts in verschiedenen Umgebungen entstehen.

2. Eingebaute Zeitzonenunterstützung: Luxon erleichtert die Konvertierung zwischen Zeitzonen, während das Date-Objekt keine robuste Unterstützung für die Zeitzonenmanipulation bietet.

3. Einfache Datumsmanipulation: Das Festlegen des Beginns oder Endes eines Tages in der lokalen Zeitzone des Benutzers und die Konvertierung in UTC ist eine häufige Aufgabe in globalen Anwendungen. Luxon vereinfacht diesen Prozess mit seiner intuitiven API, während Date eine komplexe manuelle Handhabung erfordert.

Abschluss

Der ordnungsgemäße Umgang mit Datums- und Zeitzonenkonvertierungen ist für die Erstellung zuverlässiger, benutzerfreundlicher Anwendungen von entscheidender Bedeutung. Wenn Entwickler beim Filtern von Datensätzen Zeitzonenunterschiede nicht berücksichtigen, können Benutzer wichtige Daten übersehen – was zu Verwirrung und möglicherweise kritischen Fehlern führt.

Die Verwendung von Luxon anstelle des nativen JavaScript-Datumsobjekts sorgt für Konsistenz, bessere Zeitzonenbehandlung und einfachere Manipulation von Datumsangaben. Dadurch können Entwickler ein nahtloses Erlebnis für Benutzer über Zeitzonen hinweg schaffen und sicherstellen, dass Abfragen wie erwartet funktionieren und beim Filtern keine Datensätze übersehen werden.

In globalen Anwendungen ist die genaue und zuverlässige Datumsverarbeitung der Schlüssel zur Bereitstellung eines qualitativ hochwertigen Erlebnisses für Benutzer, unabhängig von ihrer Zeitzone.

Abschließende Gedanken

Sind Sie jemals auf eine ähnliche Situation gestoßen, in der die Handhabung von Datum und Zeitzone zu unerwarteten Ergebnissen in Ihrer Anwendung geführt hat? Wie sind Sie damit umgegangen? Ich würde gerne von Ihren Erfahrungen, Ihrem Feedback oder Ihren Fragen oder Bedenken hören. Teilen Sie sie gerne im Kommentarbereich unten mit. Wenn Sie diesen Artikel hilfreich fanden, liken Sie ihn bitte und teilen Sie ihn mit anderen, die davon profitieren könnten!