Datums- und Zeitlokalisierung: Formate, Zeitzonen und die F…

Datums- und Zeitlokalisierung: Formate, Zeitzonen und die Fehler, die folgen

Wenn Sie jemals eine Funktion veröffentlicht haben, die Nutzern in Australien das falsche Datum anzeigte, oder versehentlich eine Zeit in der lokalen Zeitzone gespeichert haben, obwohl Sie UTC meinten, wissen Sie bereits, wie unnachgiebig die Datums- und Zeitverarbeitung sein kann. Das sind keine Randfälle. Das ist die Norm.

Datums- und Zeitlokalisierung liegt an der Schnittstelle zweier separater schwieriger Probleme: Internationalisierung (verschiedene Formate, Kalender, Sprachen) und verteilte Systeme (Zeitzonen, Sommerzeit-Übergänge, Uhrversatz). Eines davon falsch zu machen bedeutet, dass Nutzer Datenmüll sehen – oder schlimmer, plausibel aussehenden Datenmüll, der subtil um Stunden oder Tage daneben liegt.

Dieser Beitrag deckt den gesamten Stack ab: wie Daten gespeichert, übertragen und angezeigt werden sollten. Er enthält funktionierende Code-Beispiele in JavaScript, Python und Ruby und behandelt die spezifischen Fehler, die Teams treffen, die Details überspringen.

Das Formatierungsproblem: MM/TT/JJJJ vs. TT/MM/JJJJ vs. alles andere

Es gibt keine universell anerkannte Art, ein Datum zu schreiben. Dieser Satz allein ist für unzählige Nutzerverwirrungstickets verantwortlich.

Der häufigste Konflikt ist zwischen dem US-Format (MM/TT/JJJJ) und dem europäischen/Weltformat (TT/MM/JJJJ). Das Datum 04/05/2024 bedeutet in den USA den 5. April und in Deutschland den 4. Mai. Ohne die Spracheinstellung des Nutzers zu kennen, lässt sich aus der Zeichenkette allein nicht feststellen, welches richtig ist.

Jenseits dieses Reihenfolgekonflikt divergieren Formate weiter:

Japan, China, Korea: JJJJ/MM/TT oder YYYY年MM月DD日
ISO 8601: JJJJ-MM-TT (das einzige eindeutige Format, weshalb Sie es für die Speicherung und APIs verwenden sollten)
Indien: TT-MM-JJJJ, aber oft mit Punkten oder Schrägstrichen geschrieben
Iran, Afghanistan, Äthiopien: Verwenden völlig andere Kalender (Persisch, Äthiopisch), nicht nur unterschiedliche Reihenfolgen gregorianischer Daten

Für die Anzeige gilt: Niemals ein Datumsformat hardcoden. Leiten Sie es immer aus der Spracheinstellung des Nutzers ab. Dies ist nur eine Dimension der umfassenderen Herausforderung der Lokalisierung im Vergleich zur Internationalisierung – eine Unterscheidung, die weit mehr als nur Datumsformate betrifft. Das Verständnis von Pluralisierungsregeln in verschiedenen Sprachen ist ein weiterer verwandter Bereich, in dem spracheinstellungsspezifisches Verhalten sorgfältige Behandlung erfordert.

ISO 8601: Das einzige Format, das Sie für Speicherung und APIs verwenden sollten

Wenn Sie Daten speichern oder zwischen Services übermitteln, verwenden Sie ISO 8601. Immer. Keine Ausnahmen.

ISO 8601-Daten sehen für Daten wie 2024-04-05 aus und für Datumszeiten wie 2024-04-05T14:30:00Z. Die wichtigsten Eigenschaften, die es für den Backend-Einsatz geeignet machen:

Eindeutig: keine spracheinstellungsabhängige Reihenfolge
Sortierbar: lexikografische Sortierung entspricht chronologischer Sortierung
Zeitzone explizit: das Z-Suffix (oder +05:30-Offset) macht die Zeitzone zum Teil des Wertes
Universell unterstützt: jede wichtige Programmiersprache kann es ohne zusätzliche Bibliotheken parsen

Der häufigste einzelne Fehler bei der Datumsverarbeitung ist das Speichern einer lokalen Datums-Zeit-Zeichenkette in einer Datenbank. Wenn diese Zeichenkette auf einem Server in Frankfurt erstellt wurde, bedeutet sie eine Sache. Wenn sie auf einem Server in New York gelesen wird, bedeutet sie etwas anderes. ISO 8601 mit einem expliziten UTC-Offset beseitigt diese Mehrdeutigkeit.

# Python: Immer in UTC speichern, immer Zeitzoneninformationen einbeziehen
from datetime import datetime, timezone

# FALSCH: naives Datetime, keine Zeitzoneninformationen
bad = datetime.now()  # "2024-04-05 14:30:00" — Lokalzeit? UTC? unbekannt

# RICHTIG: zeitzonenbewusstes UTC-Datetime
good = datetime.now(timezone.utc)  # "2024-04-05T14:30:00+00:00"
good_str = good.isoformat()  # "2024-04-05T14:30:00+00:00"

// JavaScript: ISO-Zeichenketten zur Serialisierung verwenden
const now = new Date();

// FALSCH: spracheinstellungsabhängig, nicht portabel
const bad = now.toLocaleDateString(); // "4/5/2024" (US), "05.04.2024" (DE)

// RICHTIG: ISO 8601, explizit UTC
const good = now.toISOString(); // "2024-04-05T14:30:00.000Z"

# Ruby: UTC und ISO 8601 verwenden
# FALSCH
Time.now.to_s  # "2024-04-05 14:30:00 +0200" — lokale Zeitzone leckt durch

# RICHTIG
Time.now.utc.iso8601  # "2024-04-05T12:30:00Z"

Zeitzonen: In UTC speichern, lokal anzeigen

Das Leitprinzip der Zeitzonenverarbeitung ist einfach zu formulieren und unter Termindruck leicht zu vergessen: In UTC speichern, in der lokalen Zeit des Nutzers anzeigen.

UTC ist keine Zeitzone, sondern ein Standard. Er beobachtet keine Sommerzeit. Er verschiebt sich nicht. Ein UTC-Zeitstempel ist ein absoluter Zeitpunkt, der überall auf der Erde genau dasselbe bedeutet.

Wenn Sie UTC speichern und die Zeitzone des Nutzers kennen, können Sie immer die korrekte Ortszeit berechnen. Wenn Sie Ortszeit ohne Zeitzone speichern, haben Sie Informationen verloren, die Sie nicht wiederherstellen können.

Woher sollten Sie die Zeitzone des Nutzers erhalten? Mehrere Quellen, in ungefährer Reihenfolge der Zuverlässigkeit:

Explizite Nutzerpräferenz in seinem Profil gespeichert (am genauesten, nutzergesteuert)
Browser-API: Intl.DateTimeFormat().resolvedOptions().timeZone gibt die IANA-Zeitzonenzeichenkette zurück
IP-Geolokalisierung (ungefähr, schlecht für mobile Nutzer, schlägt bei VPNs fehl)

// Nutzer-Zeitzone vom Browser abrufen
const userTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
// z.B. "America/New_York", "Europe/Berlin", "Asia/Kolkata"

Sobald Sie die Zeitzone haben, übergeben Sie sie an Ihre Formatierungslogik. Versuchen Sie nicht, UTC-Zeitstempel manuell in Ortszeit umzurechnen. Verwenden Sie etablierte Bibliotheken, die Sommerzeitübergänge verstehen.

Sommerzeit: Warum manuelle Offset-Arithmetik versagt

Die Sommerzeit (DST) ist der Grund, warum Sie Zeitzonen-Offsets niemals hardcoden sollten.

"Deutschland ist UTC+1" ist die Hälfte des Jahres falsch. Deutschland beobachtet CET (UTC+1) im Winter und CEST (UTC+2) im Sommer. Wenn Sie +1 hardcoden und ein Nutzer im März um 10 Uhr ein Event erstellt, ist Ihr gespeicherter Offset im Sommer falsch und das Event erscheint zur falschen Zeit.

Die Olson (IANA)-Zeitzonendatenbank — Namen wie America/New_York, Europe/Berlin, Asia/Kolkata — enthält den vollständigen historischen und zukünftigen Zeitplan der Sommerzeitübergänge für jede Zeitzone. Jede Plattform liefert sie mit. Verwenden Sie die benannte Zeitzone, niemals einen rohen Offset.

Zu beobachtende Sommerzeitübergangsfehler:

Die mehrdeutige Stunde: Uhren werden zurückgestellt, also passiert 1:30 Uhr zweimal. "1:30 Uhr" ist ohne Kenntnis des Vorkommens mehrdeutig.
Die nicht existierende Stunde: Uhren werden vorgestellt, also existiert 2:30 Uhr nicht. Einige Parser passen stillschweigend an.
Das verschobene wiederkehrende Ereignis: Ein wöchentlich wiederkehrendes Ereignis um "15:00 Uhr Ortszeit" sollte nach einem Sommerzeitübergang um 15:00 Uhr Ortszeit bleiben — was bedeutet, dass sich die UTC-Zeit um eine Stunde ändert.

// JavaScript: Die Intl-API die Sommerzeit für Sie verwalten lassen
const formatter = new Intl.DateTimeFormat('de-DE', {
  timeZone: 'Europe/Berlin',
  hour: '2-digit',
  minute: '2-digit',
  day: '2-digit',
  month: '2-digit',
  year: 'numeric',
});

// Sicher sowohl in CET als auch in CEST
const utcDate = new Date('2024-03-31T01:30:00Z'); // Sommerzeitübergangstag in Europa
console.log(formatter.format(utcDate)); // "31.03.2024, 03:30"

# Python: zoneinfo (Python 3.9+) oder pytz verwenden
from zoneinfo import ZoneInfo
from datetime import datetime

utc_time = datetime(2024, 3, 31, 1, 30, tzinfo=ZoneInfo("UTC"))
berlin_time = utc_time.astimezone(ZoneInfo("Europe/Berlin"))
print(berlin_time)  # 2024-03-31 03:30:00+02:00 — sommerzeitbewusste Konvertierung

# Ruby: TZInfo-Gem für zuverlässige Sommerzeitverarbeitung verwenden
require 'tzinfo'

tz = TZInfo::Timezone.get('Europe/Berlin')
utc = Time.utc(2024, 3, 31, 1, 30)
local = tz.utc_to_local(utc)
# Gibt sommerzeitangepasste Zeit korrekt zurück

JavaScript Intl.DateTimeFormat: Der richtige Weg zur Datumsformatierung

Die Intl.DateTimeFormat-API ist in jede moderne JavaScript-Laufzeitumgebung eingebaut. Sie verarbeitet spracheinstellungsspezifische Formatierung, Zeitzonenumrechnung und Kalendersysteme ohne externe Abhängigkeiten.

// Grundlegende spracheinstellungsbewusste Datumsformatierung
const date = new Date('2024-08-15T09:00:00Z');

// Amerikanisches Englisch
new Intl.DateTimeFormat('en-US', { dateStyle: 'long' }).format(date);
// "August 15, 2024"

// Deutsch
new Intl.DateTimeFormat('de-DE', { dateStyle: 'long' }).format(date);
// "15. August 2024"

// Japanisch
new Intl.DateTimeFormat('ja-JP', { dateStyle: 'long' }).format(date);
// "2024年8月15日"

// Mit Uhrzeit und Zeitzone
new Intl.DateTimeFormat('en-GB', {
  dateStyle: 'full',
  timeStyle: 'short',
  timeZone: 'Europe/London',
}).format(date);
// "Thursday, 15 August 2024 at 10:00"

Relative Zeitformatierung (z.B. "vor 3 Stunden") verwendet Intl.RelativeTimeFormat:

const rtf = new Intl.RelativeTimeFormat('fr-FR', { numeric: 'auto' });

rtf.format(-1, 'day');   // "hier" (gestern)
rtf.format(-3, 'hour');  // "il y a 3 heures"
rtf.format(2, 'week');   // "dans 2 semaines"

Beachten Sie, dass Intl.RelativeTimeFormat erfordert, dass Sie den Wert und die Einheit berechnen. Es berechnet nicht selbst, ob etwas "gestern" oder "vor 3 Tagen" war. Bibliotheken wie date-fns oder Temporal (der Nachfolger der aktuellen Date-API) schichten diese Logik auf Intl auf.

Python und Ruby: Babel, strftime und ihre Grenzen

Python: Babel für spracheinstellungsbewusste Formatierung

Die Standardbibliothek strftime in Python erzeugt nur über die Systemspracheinstellung spracheinstellungsbewusste Ausgabe, was in Produktionsumgebungen unzuverlässig ist. Für ordentliche i18n verwenden Sie Babel:

from babel.dates import format_date, format_datetime, format_time
from datetime import datetime, timezone

dt = datetime(2024, 8, 15, 9, 0, 0, tzinfo=timezone.utc)

# Für verschiedene Spracheinstellungen formatieren
format_date(dt, locale='en_US')    # 'Aug 15, 2024'
format_date(dt, locale='de_DE')    # '15.08.2024'
format_date(dt, locale='ja_JP')    # '2024/08/15'
format_date(dt, format='long', locale='ar_SA')  # '١٥ أغسطس ٢٠٢٤'

# Mit Zeitzonenkonvertierung
from babel.dates import get_timezone
format_datetime(
    dt,
    format='full',
    tzinfo=get_timezone('America/New_York'),
    locale='en_US'
)
# 'Thursday, August 15, 2024 at 5:00:00 AM Eastern Daylight Time'

Ruby: strftime ist spracheinstellungsblind

Rubys eingebautes strftime ist nicht spracheinstellungsbewusst. Time.now.strftime('%B %d, %Y') erzeugt unabhängig von der Anwendungsspracheinstellung immer englische Monatsnamen. Für spracheinstellungsbewusste Ausgabe verwenden Sie das i18n-Gem (Standard in Rails) mit spracheinstellungsspezifischen Formatzeichenketten oder twitter_cldr für CLDR-basierte Formatierung:

require 'twitter_cldr'

date = DateTime.new(2024, 8, 15, 9, 0, 0)

# Englisch
date.localize(:en).to_long_s  # "August 15, 2024"

# Deutsch
date.localize(:de).to_long_s  # "15. August 2024"

# Japanisch
date.localize(:ja).to_long_s  # "2024年8月15日"

# Relative Zeit
time_ago = 3.hours.ago
time_ago.localize(:fr).ago.to_s  # "il y a 3 heures"

In Rails-Anwendungen ist I18n.l(date, format: :long) mit Spracheinstellungs-YAML-Dateien der konventionelle Ansatz, aber die Formatzeichenketten in diesen YAML-Dateien erfordern immer noch manuelle Lokalisierung für jede Sprache.

Häufige Fehler, die Produktionsfehler verursachen

1. Lokalzeit in der Datenbank speichern

-- FALSCH: In welcher Zeitzone ist das?
created_at DATETIME DEFAULT NOW()

-- RICHTIG: Immer UTC speichern
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() AT TIME ZONE 'UTC'

Wenn Ihr Datenbankspaltenttyp DATETIME ohne Zeitzonenbewusstsein ist, haben Sie bereits Informationen verloren. Wechseln Sie zu TIMESTAMP WITH TIME ZONE (oder Äquivalent) und stellen Sie sicher, dass Ihre Anwendungsschicht immer UTC schreibt.

2. JavaScript Date() zum Parsen von Nicht-ISO-Zeichenketten verwenden

// FALSCH: Parsing-Verhalten ist für Nicht-ISO-Zeichenketten implementierungsdefiniert
new Date('05/04/2024')  // 4. Mai oder 5. April? Hängt von der Umgebungsspracheinstellung ab

// RICHTIG: Nur ISO 8601-Zeichenketten parsen, oder eine Bibliothek verwenden
new Date('2024-05-04')  // Immer 4. Mai 2024

3. Annehmen, dass die Server-Zeitzone UTC ist

Viele Cloud-Umgebungen verwenden standardmäßig UTC, aber viele nicht. Code, der annimmt, dass new Date() UTC zurückgibt, ohne TZ-Umgebungsvariablen zu prüfen, verhält sich in verschiedenen Deployments unterschiedlich.

// FALSCH: Geht davon aus, dass der Server UTC ist
const today = new Date().toISOString().split('T')[0];

// RICHTIG: Explizit sein, was Sie berechnen
const todayUTC = new Date().toISOString().split('T')[0]; // Das IST UTC über toISOString
// Aber wenn Sie "heute in der Zeitzone des Nutzers" wollen:
const todayLocal = new Intl.DateTimeFormat('en-CA', {
  timeZone: userTimezone
}).format(new Date()); // "2024-08-15"

4. Mitternacht ist kein sicherer Standardzeitpunkt

Wenn Sie ein Ereignis um Mitternacht UTC an einem bestimmten Datum erstellen, liegt dieses Ereignis für Nutzer in UTC-5 bis UTC-12 am vorherigen Tag. "Ganztägige Ereignisse" sollten nur ein Datum (JJJJ-MM-TT) speichern, kein Datetime.

5. Offset als Zeitzone behandeln

+05:30 ist ein Offset, keine Zeitzone. Indien (Asia/Kolkata) ist immer UTC+5:30 und beobachtet keine Sommerzeit, also ist die Unterscheidung hier harmlos. Aber für +10:00 könnte das Australia/Sydney (beobachtet DST) oder Pacific/Port_Moresby (tut es nicht) sein. Speichern Sie immer den IANA-Zeitzonennamen neben oder statt des rohen Offsets.

Nutzer-Zeitzonenpräferenzen in Webanwendungen verwalten

Eine vollständige Implementierung benötigt drei Dinge:

Zeitzone bei der Anmeldung erkennen oder erfassen: Verwenden Sie die Browser-API als Standard, lassen Sie Nutzer sie in den Einstellungen überschreiben.
Die IANA-Zeitzonenzeichenkette im Nutzerprofil speichern: Kein Offset, kein Stadtname.
Zum Render-Zeitpunkt anwenden, nicht zum Speicherzeitpunkt: Zeitstempel bleiben UTC in der Datenbank; die Konvertierung erfolgt in der Anwendungsschicht bei der Anzeige für den Nutzer.

// Im Frontend: erkennen und an das Backend senden
const detectedTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;

// Bei der Anmeldung oder beim Profilspeichern:
await api.updateProfile({ timezone: detectedTimezone });

// Beim Rendern von Daten, die von der API empfangen wurden:
function formatEventTime(isoString, userTimezone, locale) {
  return new Intl.DateTimeFormat(locale, {
    timeZone: userTimezone,
    dateStyle: 'medium',
    timeStyle: 'short',
  }).format(new Date(isoString));
}

// Verwendung
formatEventTime('2024-08-15T14:30:00Z', 'Asia/Tokyo', 'ja-JP');
// "2024/08/15 23:30"

Auf der Serverseite, wenn Sie "alle Ereignisse für einen Nutzer an einem bestimmten Kalendertag" interpretieren müssen, müssen Sie sein "heute" in einen UTC-Bereich umrechnen:

from datetime import datetime
from zoneinfo import ZoneInfo

def get_day_utc_range(date_str: str, user_timezone: str):
    """Konvertiert ein lokales Datum in einen UTC-Datetime-Bereich."""
    tz = ZoneInfo(user_timezone)
    local_start = datetime.fromisoformat(f"{date_str}T00:00:00").replace(tzinfo=tz)
    local_end = datetime.fromisoformat(f"{date_str}T23:59:59").replace(tzinfo=tz)
    utc_start = local_start.astimezone(ZoneInfo("UTC"))
    utc_end = local_end.astimezone(ZoneInfo("UTC"))
    return utc_start, utc_end

# "Heute" für einen Nutzer in Tokio ist ein anderer UTC-Bereich als für einen Nutzer in New York
start, end = get_day_utc_range("2024-08-15", "Asia/Tokyo")
# Abfrage: WHERE created_at BETWEEN start AND end

Datumslokalisierung testen

Dateumslokalisierungsfehler sind in der Entwicklung oft unsichtbar, weil Entwickler und CI-Server dazu neigen, in derselben Zeitzone zu sein. Tests müssen explizit Folgendes abdecken:

Mehrere Spracheinstellungen: Mindestens en-US, de-DE, ja-JP, ar-SA testen (RTL + verschiedene Ziffern)
Sommerzeitübergangsdaten: März und November (nördliche Hemisphäre), September und April (südliche Hemisphäre)
Zeitzonenrandfälle: Mit UTC-12, UTC+14, Indien (UTC+5:30), Nepal (UTC+5:45) testen
Jahr-/Monatsgrenzen: 31. Dezember bis 1. Januar über Zeitzonen

// Jest: Mit festen Daten testen, um Instabilität zu vermeiden
describe('formatEventTime', () => {
  const testCases = [
    {
      input: '2024-03-31T01:30:00Z', // Sommerzeitübergang in Europa
      timezone: 'Europe/Berlin',
      locale: 'de-DE',
      expected: '31.03.2024, 03:30', // Springt auf 03:30 vor
    },
    {
      input: '2024-08-15T14:30:00Z',
      timezone: 'Asia/Kolkata',
      locale: 'hi-IN',
      expected: '15/8/2024, 8:00 pm', // UTC+5:30
    },
  ];

  test.each(testCases)('Formatiert korrekt für $locale in $timezone', ({ input, timezone, locale, expected }) => {
    expect(formatEventTime(input, timezone, locale)).toBe(expected);
  });
});

Für CI-Umgebungen setzen Sie die TZ-Umgebungsvariable explizit auf UTC, um zu verhindern, dass Tests von der lokalen Zeitzone des Servers abhängen:

TZ=UTC npx jest

Datensverarbeitung ist auch eng mit anderen spracheinstellungsspezifischen Konventionen verbunden, die globale Produkte stolpern lassen. Wenn Sie für mehrere Märkte entwickeln, sind Pluralisierungsregeln in verschiedenen Sprachen und korrekte i18n-SEO-Implementierung mit Hreflang-Tags verwandte Bereiche, die es neben der Zeitzonenverarbeitung zu prüfen lohnt. Teams, die Internationalisierungstests ernst nehmen, sollten sich auch umfassende i18n-Teststrategien ansehen, die über reine Datumsformate hinausgehen.

Wo Better i18n passt

Manuelle Datumsformatierung ist lösbar — die Intl-API und Bibliotheken wie Babel verwalten die Rendering-Schicht gut. Das schwierigere Problem ist die Skalierung: Wenn Sie eine Anwendung haben, die 20 Spracheinstellungen bedient, müssen Datumsformatpräferenzen über jede Komponente, jede E-Mail-Vorlage und jeden Export hinweg konsistent sein. Diese Konsistenz bricht zusammen, wenn Teams wachsen.

Better i18n adressiert dies, indem Ihr Anwendungscode spracheinstellungsbewusste Formatschlüssel referenzieren kann, anstatt Intl-Optionen in jeder Komponente hardzucodieren. Wenn ein Format für eine Spracheinstellung geändert werden muss — sagen wir, Sie entdecken, dass Ihre deutschen Nutzer einen anderen Datumsstil bevorzugen — aktualisieren Sie es an einem Ort, anstatt Komponentendateien zu durchsuchen.

Für React-Anwendungen deckt die Funktionsseite Integrationen ab, die Spracheinstellungskontext mit Datumsformatierung kombinieren, sodass Komponenten Daten immer im bevorzugten Format der aktiven Spracheinstellung rendern, ohne dass jede Komponente ihre eigene Intl.DateTimeFormat-Instanz verwaltet.

Die Funktionsseite deckt CDN-Auslieferung von Spracheinstellungsdaten ab, was bei der Datumsformatierung wichtig ist, weil das vollständige CLDR-Dataset für alle Spracheinstellungen groß ist. Das Lazy-Loading von Spracheinstellungsdaten bei Bedarf — anstatt alles zu bündeln — hält die anfänglichen Seitengewichte niedrig, ohne die Korrektheit zu opfern.

Zusammenfassung

Datens- und Zeitlokalisierung ist kein kosmetisches Problem. Die Fehler, die sie produziert, sind Korrektheitsfehler: Ereignisse am falschen Tag, Zeitstempel, die nach der Sommerzeit verschieben, Daten, die für Nutzer in verschiedenen Regionen unterschiedliches bedeuten.

Die Praktiken, die die meisten Probleme verhindern:

ISO 8601 UTC überall speichern und übertragen: Datenbanken, APIs, Logs
IANA-Zeitzonennamen neben Nutzerdatensätzen speichern (z.B. America/New_York), keine rohen Offsets
Intl.DateTimeFormat in JavaScript statt manueller Formatzeichenketten verwenden
Babel (Python) oder twitter_cldr (Ruby) für spracheinstellungsbewusste Formatierung in Backend-Code verwenden
Niemals Zeitzonenoffsets hardcoden — die IANA-Datenbank über die Standardbibliothek Ihrer Laufzeitumgebung verwenden
Explizit testen an Sommerzeitübergangsdaten, über mehrere Zeitzonen und mit mehreren Spracheinstellungen

Die Speicher- und Übertragungsschichten sind weitgehend sprachunabhängig: ISO 8601 und UTC funktionieren überall. Die Anzeigeschicht ist dort, wo spracheinstellungsspezifische Logik lebt, und das ist, wo Tools und Bibliotheken die meiste Zeit sparen. Eine solide Grundlage in der Datums-/Zeitverarbeitung ist ein Teil der umfassenderen Disziplin der globalen Inhaltslokalisierung — jeden Aspekt Ihres Produkts für jeden Markt nativ anfühlen zu lassen.

Machen Sie Ihre App global mit better-i18n

better-i18n kombiniert KI-gestützte Übersetzungen, git-native Workflows und globale CDN-Auslieferung in einer entwicklerorientierten Plattform. Hören Sie auf, Tabellenkalkulationen zu verwalten, und beginnen Sie, in jeder Sprache zu liefern.

Kostenlos starten → · Funktionen erkunden · Dokumentation lesen

Datums- und Zeitlokalisierung: Formate, Zeitzonen und die Fehler, die folgen