Teuer ist nicht das Format. Teuer ist die Annahme.
Ein Datum wie 05/06/2026 sieht harmlos aus, bis zwei Menschen es unterschiedlich lesen. In Deutschland, Österreich und der Schweiz liegt bei numerischen Daten meist Tag-Monat-Jahr nahe. In den USA bedeutet dieselbe Schreibweise oft May 6. In einem internationalen Team reicht dann eine kurze Nachricht wie “Friday at 3” für Verwirrung.
Gute Datums- und Zeitangaben sind keine Bürokratie. Sie entfernen versteckte Annahmen. Niemand sollte Ihr Land, Ihre Kalendereinstellungen oder die aktuelle Sommerzeitregel erraten müssen.
Denken Sie vom Leser aus
Im deutschsprachigen Raum ist 05.06.2026 verständlich. In internationalen Systemen ist 2026-06-05 robuster. Für Menschen ist “Freitag, 5. Juni 2026” oft am klarsten.
| Zielgruppe | Riskant | Klarer |
|---|---|---|
| DACH-Raum | 5/6/26 | 5. Juni 2026 |
| Europa und USA | 05/06/2026 | 2026-06-05 (5. Juni) |
| Systeme, Dateien, Logs | bericht final juni 5 | 2026-06-05-bericht-final |
| Vertrag oder Hinweis | Nächsten Freitag | Freitag, 5. Juni 2026 |
ISO 8601, wenn ein Datum reisen muss
YYYY-MM-DD ist nüchtern, aber stark. Es sortiert korrekt, vermeidet US/EU-Verwechslungen und eignet sich für Dateinamen, Datenbanken, Tickets, Tabellen und APIs. Für Menschen ergänzen Sie den ausgeschriebenen Tag: 2026-06-05 (Freitag, 5. Juni).
Keine Uhrzeit ohne Ort
“Um 3” ist keine internationale Uhrzeit. Nennen Sie eine Stadt, eine IANA-Zone, UTC oder senden Sie eine korrekt konfigurierte Kalendereinladung. Für wiederkehrende Termine ist Europe/Berlin, Europe/Vienna oder Europe/Zurich besser als nur UTC+1, weil sich der Offset mit der Sommerzeit ändert.
| Schreibweise | Einsatz | Warum |
|---|---|---|
| 15:00 Uhr Berlin | Nachricht an Menschen | Der relevante lokale Kalender ist klar. |
| 2026-06-05T13:00:00Z | Systeme, APIs, Logs | Ein exakter UTC-Zeitpunkt. |
| 09:00 Europe/Berlin | Wiederkehrende Termine | Erhält die lokale Uhrzeit über Sommerzeitwechsel. |
| 15:00 UTC+02:00 | Einmaliger Timestamp | Für diesen Moment klar, für Wiederholungen schwach. |
Abkürzungen sind riskant
CST, IST oder BST können je nach Land unterschiedliche Dinge bedeuten. Auch CET und CEST werden in Mails oft unsauber gemischt. Wenn es wichtig ist, schreiben Sie die Stadt oder IANA-Zone: 09:00 Europe/Berlin.
24-Stunden-Zeit ist international oft besser
Im deutschsprachigen Alltag ist das 24-Stunden-Format üblich: Bahn, Medizin, Behörden, Arbeit. Es verhindert Verwechslungen zwischen Morgen und Abend. Bei Empfängern mit AM/PM-Gewohnheit kann eine doppelte Angabe helfen: 3:00 PM / 15:00 Berlin time.
Kalenderwochen brauchen eine Regel
ISO-Kalenderwochen beginnen am Montag. Woche 1 ist die Woche mit dem ersten Donnerstag des Jahres. In Produktion, Logistik und vielen deutschen Unternehmen ist das normal; international ist es nicht selbstverständlich. Schreiben Sie daher den Datumsbereich dazu: 2026-W23, Montag 1. Juni bis Sonntag 7. Juni.
Ein gemeinsamer Teamstil
| Angabe | Empfohlen | Beispiel |
|---|---|---|
| Datum | ISO plus ausgeschrieben | 2026-06-05 (Freitag, 5. Juni) |
| Einzeltermin | Lokalzeit plus UTC | 15:00 Berlin / 13:00 UTC |
| Wiederkehrender Termin | IANA-Zone plus Lokalzeit | 09:00 Europe/Berlin jeden Dienstag |
| Frist | Datum, Uhrzeit, Zone, Wochentag | Freitag, 5. Juni 2026, 17:00 Europe/Berlin |
| Kalenderwoche | ISO-Woche plus Bereich | 2026-W23, 1.-7. Juni |
Vor dem Absenden
- Könnte das Datum amerikanisch und europäisch gelesen werden?
- Nennt die Uhrzeit Stadt oder Zone?
- Ist es ein wiederkehrender Termin über einen Sommerzeitwechsel hinweg?
- Wäre 24-Stunden-Zeit eindeutiger?
- Ist bei Kalenderwochen ISO oder der Datumsbereich genannt?
Gute Angaben wirken manchmal redundant. Genau das schützt vor verpassten Calls, falschen Fristen und falsch gruppierten Berichten.