| Zu allen Zeiten wurden lokale und nationale Varianten der verschiedensten Dinge ausgedacht. In den USA entstanden historisch einige besonders kuriose Standards zur Formulierung von Datum & Zeit. | Nationale und lokale Standards sind überholt und längst durch den internationalen Standard ISO-8601 ersetzt. Die USA halten zäh an ihren komplizierten Varianten fest. Wegen des starken Einflusses der USA muss man sich daher leider weltweit (auch) mit diesem Problem herumschlagen. |
Datum & Zeit
|
Schnittpunkt von uralter Kultur und Informationstechnik |
| RFC-822 | Veraltete Familie von nationalen US-Standards für Datum & Zeit-Texte |
| Live | Live-Demonstration einiger Format-Varianten |
| Woche | Berechnung der US-Kalenderwoche |
| ISO-8601 | Der internationale Standard zur weltweit eindeutigen Formatierung |
| Entwicklung | ISO-8601 in Systemen, Programmen und Programmiersprachen |
RFC-822: Der überholte US-nationale Familie von Datum-Zeit-Strings |
|
|
In den USA wurde historisch eine ganze Reihe nationaler Standards zur Formulierung
von Datum und Zeit entwickelt. Alle diese Formate wurden mittlerweile durch den international eindeutigen Standard → ISO-8601 abgelöst, der theoretisch auch in den USA anerkannt ist. ▼ Leider haben die zahlreichen umständlichen US-Formate mehr als nur lokale Bedeutung. Wegen der führenden Stellung der USA in der Informatik-Urzeit wurden einige davon in verschiedenen IT-Bereichen verankert und bis heute noch nicht ersetzt. Live-↓ Beispiel auf dieser Seite. |
▼
Dabei handelt es sich um viele verschiedene Versionen. Allen gemeinsam ist die schlechte
Verständlichkeit im Rest der Welt. Das liegt zum Teil an der Verwendung von
englischen Monats- und Wochentags-Namen, teils an der ausgefallenen Reihenfolge der
einzelnen Komponenten. ▼ Die Texte lassen sich alphabetisch nicht korrekt sortieren. ▼ Länge und Position der einzelnen Komponenten sind meist variabel. ▼ Der IT-Aufwand zur Decodierung und Validierung dieser Formate ist unangemessen hoch. |
| ▼ Nationale oder lokale Standards wie RFC-822 oder die deutsche Norm DIN-5008 stellen eine erhebliche Behinderung beim Austausch von Daten dar. | ▼ Niemand außerhalb der USA verwendet freiwillig diese Formate. Sie sind schlecht verständlich, werden oft falsch interpretiert und benötigen viel Aufwand zur automatischern Verarbeitung. Dennoch wird es lange dauern, sie vollständig aus der Informatik zu verdrängen. |
| Der Standard RFC-822 wurde bereits für den Internet-Vorläufer Arpanet entwickelt. Er wird im E-Mail Verkehr noch immer verwendet. | Einige Ergänzungn: RFC-1123 (fixe Stringlänge), RFC-850 und RFC-1036 (variablen Stringlänge, 2stellige Jahreszahl), RFC-2822 usw. |
Auswahl der RFC-822 Format-Familie |
|||||||||||||
Einige der häufigeren US-RFC-Varianten (ohne Gewähr):
|
Analog zur RFC-822-Familie gibt es weltweit zahlreiche nationale Standards für
Datum-Zeit-Strings - Sie haben jedoch in keinem Fall mehr als lokale Bedeutung erlangt
und verdienen ebenso wie RFC-822 die langsame Verdrängung durch Formate,
die weltweit eindeutig verstanden werden. Auch in den USA ist → ISO-8601 als Standard anerkannt, wird jedoch (derzeit) nur von der Armee und einigen Berufsgruppen verwendet, die auf internationale Zusammenarbeit angewiesen sind. Wenn verfügbar, kann man RFC-3339 verwenden. |
||||||||||||
US-Kalenderwoche |
|
| Im Geschäftsverkehr wird häufig die Kalenderwoche verwendet (week of year WOY). Die Berechnung der US-WOY erfolgt nach einem anderen Algorithmus als im Rest der Welt. |
In der EU gilt die Kalenderwoche nach Standard
→ ISO-8601. Meist fallen
nur die Sonntage in eine andere Woche, daher wird der Unterschied nicht immer bemerkt. • LibreOffice oder OpenOffice berechnen wahlweise ISO-KW oder US-WOY. • MS-Excel berechnet derzeit ohne Warnung oder Hinweis (!) nur die US-WOY. |
|
Algorithmus der US-WOY (ohne Gewähr):
•
US-Wochen beginnen am Sonntag und enden am folgenden Samstag.
• Am 1. Jänner beginnt immer WOY=1 • Am Anfang und Ende jedes Jahres sind Teil-Wochen zugelassen. |
Wenn man die ersten und letzten Tage der Kalenderjahre (für den Geschäftsverkehr) nicht berücksichtigt, dann liegen US- und Standard-Wochentage in 5/7 = 72% der Jahre in der gleichen KW. In 2/7 = 28% der Jahre liegt die US-WOY um +1 vor der ISO-KW (z.B. 2010, 2011, 2016...). Die Differenz kann bei Missverständnissen finanziell schmerzhaft werden. |
|
Wichtige Differenzen ergeben sich am Anfang und Ende der meisten Jahre.
Dort ergibt der US-Algorithmus unvollständige Teil-Wochen. Fast alle US-Jahre, jedoch nur ca. 18% der EU-Jahre enden mit WOY=53. |
Als Kuriosität ergibt sich im Mittel alle 29.5 Jahre am Sylvester-Tag eine
1-Sonntags-Woche mit WOY=54 (z.B. 2028-12-31). ♦ Details zur Berechnung von ISO-KW und US-Kalenderwochen, Algorithmen, Programm-Beispiele, etc. |
WochentagUS-Wochen dauern von Sonntag bis Samstag !
Viele Funktionen von Programmen und Programmiersprachen liefern kommentarlos eine
Wochentags-Nummer nach US-Vorstellung.
|
Bei Wochentags-Nummern 1..7 wird die Differenz zur ISO-Norm (Montag bis Sonntag) meist bemerkt, bei 0..6 ergeben sich häufig Programm-Fehler. Tipp: Testen sie stets eine vollständige Woche ! |
ISO-8601: Der internationale Standard für Datum-Zeit-Strings |
|
| Der international eindeutige Standard ISO-8601 (rechts) sollte lokale und nationale Datum & Zeit-Texte in jedem Fall ablösen. |
yyyy-mo-dd
hh:mi:ss
|
Vorteile von ISO-8601• Sowohl für Mensch als auch für Technik (Software) gut verwendbar.• In allen Kulturen der Welt eindeutig und unmissverständlich, insbesondere auch in den USA. • Fixe Position und Länge aller Bestandteile. Das erleichtert die Kontrolle und vermeidet Fehler durch falsche Interpretation. • Lässt sich durch Hinzufügen oder Weglassen von Bestandteilen an jede gewünschte Genauigkeit anpassen. |
• Wesentlich einfachere Interpretation durch Software. Lässt sich daher rascher, sicherer und kostengünstiger automatisch verarbeiten. • Klare Regeln für die Angabe von Kalenderwoche, Wochentag, Tag des Jahres und Zeitzone. • Korrekte alphabetische Sortierung auf allen Betriebssystemen. ♦ Details zum Standard ISO-8601 |
Programmierung von RFC-822-Strings |
|
Linux-Konsole (shell)
# date
# date --rfc-2822 # date "+%x" # date "+%D %r" # date "+%a, %e %h %Y %T" # man date ♦ Details zu Datum & Zeit @ Linux |
Win-Konsole (cmd.exe)
C:\> date /T
Keine RFC-Formatierung, kann aber programmiert werden.C:\> time /T ♦ Details zu Datum & Zeit @ Windows, CygWin |
ProgrammiersprachenAlle modernen Programmiersprachen bieten die POSIX Funktion strftime, mit der sich alle denkbaren Datum & Zeit-Texte erzeugen lassen. Alternativ (wenn angeboten meist wesentlich schneller) kann man die Funktion date verwenden.Zusätzlich bieten manche Sprachen spezielle Funktionen, meist in eigenen darauf spezialisieren Modulen. |
Beispiele (PHP):
$t="%c";
// $t="%D %r";
print strftime($t,time());
// $t="%a, %e %h %Y %H:%M:%S"; ♦ Details zu Datum & Zeit in C/C++, Javascript, Perl, PHP, VBA |
DecodierungWesentlich aufwändiger als die Erzeugung (Codierung) eines Datum & Zeit-Strings ist die Decodierung, d.h. Aufspaltung in die Bestandteile und deren korrekte Interpretation.Wegen der unabsehbar großen Anzahl von Varianten gibt es kaum Unterstützung durch Standard-Funktionen. Am besten eignen sich dazu → Reguläre Ausdrücke (RegExp). Im Idealfall ist nur eine einzige genau bekannte Version zu decodieren. In jedem anderen Fall ist der Aufwand groß und der Erfolg ungewiss ! ♣ Versuchen sie zuerst, die Zeit zu isolieren: Meist ähnlich ISO-Format, manchmal ohne führende Nullen. Vorsicht - Angabe in Lokalzeit oder UTC ! ♣ Das Jahr ist (nur dann) leicht zu finden, wenn es 4stellig enthalten ist. Die Einschränkung auf Jahre 2000..2099 ist hilfreich. ♣ Das Monat kann an seinen 3 Anfangs-Buchstaben erkannt werden, weniger eindeutig an einem numerischen Wert. ♣ Am schwierigsten ist der Tag des Monats. Man muss seine Position mit Hilfe von Indizien herausfinden. ♣ Die Zeitzone steht - wenn angeführt - meist am Ende des Strings. GMT oder UTC oder Z bezeichnen die Weltzeit, CET die Mitteleuropäische Zeit. Der Zeit-Abstand der Zeitzone wird numerisch nach + oder - Zeichen angegeben. |
Beispiel (vereinfacht):
Javascript Demo + Live-Ergebnis: Das Format ist leider abhängig von System,
Browser und Version !
var dlm = document.lastModified;
document.lastModified
Zeit:
dlm.match(/(\d+):(\d+):(\d+)/);
hh:mi:ss
Jahr:
dlm.match(/(20\d\d)/);
yyyy
Monat, Tag (US-Format):
dlm.match(/(\d+)\/(\d+)\/(\d+)/);
mo/dd/yyyy
Monat, Tag (US-RFC-Format):
dlm.match(/, (\d+) (...) (20\d\d)/);
dd mon yyyy
♦ Details und Beispiele zu Regulären Ausdrücken (RegExp). |