Y2K-Problem

[Deus Figendi]

Guten Morgen,
ich bin gerade dabei ein (bzw. mehrere) RSS-Feed zu parsen, dabei ist das Datum von großer Relevanz.
Da TCL (in der Sprache mache ich das) von Haus aus keine Datums-Funktionen mitbringt zerlege ich die Daten "von Hand" (es gibt eine Date-Bibliothek die man nachladen kann will ich aber nicht...).
Da kommt mir zugute, dass die RSS-Spezifikation reichlich genau das Datums-Format festlegt, ich muss also nicht raten ob national oder international oder sonst was.
Allerdings bezieht sich die Spezifikation an der Stelle auf ein uraltes RFC (1982) welches in Abschnitt 5 Daten definiert:
date        =  1*2DIGIT month 2DIGIT
Das RFC sagt also klipp und klar: "Jahr" hat zwei Stellen!
(warum man "Monat" als 3-Zeichen-Abkürzung macht erschließt sich mir nicht spart nämlich nicht gerade Bandbreite/Speicher ist mir aber auch egal)
In the wild habe ich ehrlich gesagt noch kein RSS-Feed gesehen, welches sich daran hält, aber es könnte ja sein. Die Frage ist: Wie gehe ich am Besten damit um?
Es hat sich ja ein bisschen eingebürgert, dass man Werte >1999 tendenziell eher vierstellig schreibt. Also _KÖNNTE_ ich annehmen dass zweistellige immer älter als 2k sind.
Andererseits geht es hier in der Regel um recht aktuelle Daten (rss => "News feed" also idR recht new) also _KÖNNTe_ ich ebenso annehmen, dass das Datum eher dazu tendiert recht jung zu sein.
Dritte Lösung (die mir beim Schreiben dieses Beitrags einfällt): Man könnte auch ein Stich-Datum machen an dem es sich scheidet. Am Ehesten böten sich wohl '50 (Mitte) oder '70 (Timestamp-Refferenz) an. Will sagen dass ich Daten vor dem Stich-Datum den 2000ern und nach dem Stich-Datum den 1900ern zuordne.

Ich bin einfach unentschlossen, was die beste Praxis wäre.
(Und ich find's blöd dass sich RSS scheinbar auf dieses uralte RFC bezieht ohne eine Änderung zu spezifizieren, man hätte auch einfach das XML-Datums-Format nehmen können, welches YYYY-MM-DDThh:mm:ss zzgl. Timezone verwendet *grummel*)

Hmmm ich hätte es auch unter "Meinung" einstellen können ^^
Vielen Dank schonmal

[hotti]

moin,

Das RFC sagt also klipp und klar: "Jahr" hat zwei Stellen!

Was völlig ausreichend ist. Oder hast Du Feeds aus dem vorigen Jahrtausend parsen?

Hotti

PS: Das Jahr 2099 erleben wir doch sowieso nicht mehr.

[Der Martin]

Hallo,

Allerdings bezieht sich die Spezifikation an der Stelle auf ein uraltes RFC (1982) welches in Abschnitt 5 Daten definiert:
date        =  1*2DIGIT month 2DIGIT
Das RFC sagt also klipp und klar: "Jahr" hat zwei Stellen!

das ist blöd, keine Frage. Ich mein, man hätte auch 1982 schon vorausschauend das Jahr vierstellig festlegen können; dass man sich aber heute bzw. beim Ausarbeiten der RSS-Spezifikation auf ein altes Dokument beruft, das seinerseits schon längst überholt ist, finde ich reichlich ungeschickt.

In the wild habe ich ehrlich gesagt noch kein RSS-Feed gesehen, welches sich daran hält

Das heißt was? Setzen die das Jahr meist doch vierstellig ein?

aber es könnte ja sein. Die Frage ist: Wie gehe ich am Besten damit um?

Flexibel. Aber das hast du ja schon erkannt, dass das dann wohl nötig ist. ;-)

Es hat sich ja ein bisschen eingebürgert, dass man Werte >1999 tendenziell eher vierstellig schreibt. Also _KÖNNTE_ ich annehmen dass zweistellige immer älter als 2k sind.

Nein. Ich weiß nicht, wie RSS-Ersteller "ticken", aber ich kenne eine Menge Leute, die auch heute, lange nach 2000, die Jahreszahl nur zweistellig schreiben.

Dritte Lösung (die mir beim Schreiben dieses Beitrags einfällt): Man könnte auch ein Stich-Datum machen an dem es sich scheidet. Am Ehesten böten sich wohl '50 (Mitte) oder '70 (Timestamp-Refferenz) an. Will sagen dass ich Daten vor dem Stich-Datum den 2000ern und nach dem Stich-Datum den 1900ern zuordne.

So macht es Windows, wenn eine zweistellige Jahreszahl interpretiert werden soll. Ich finde diese Lösung gut, sie kommt der Wirklichkeit vermutlich am nächsten. Zusätzlich so flexibel parsen, dass vierstellige Jahreszahlen auch richtig verstanden werden.

(Und ich find's blöd dass sich RSS scheinbar auf dieses uralte RFC bezieht ohne eine Änderung zu spezifizieren, man hätte auch einfach das XML-Datums-Format nehmen können, welches YYYY-MM-DDThh:mm:ss zzgl. Timezone verwendet *grummel*)

So als würde man bei der Neufassung eines deutschen Gesetzes auf eine Vorschrift aus dem römischen Reich verweisen.

So long,
 Martin

[dedlfix]

Hi!

Das RFC sagt also klipp und klar: "Jahr" hat zwei Stellen!
das ist blöd, keine Frage. Ich mein, man hätte auch 1982 schon vorausschauend das Jahr vierstellig festlegen können;

RFCs beschreiben manchmal auch Dinge wie sie sind, nicht nur wie man sie sich für die Zukunft vorstellt. "Request for Comment" könnte in diesem Fall auch einach nur kommentieren. (Anderes Beispiel: Das CSV-Format war auch lange vorher bekannt und verbreitet, bevor es in eine RFC gegossen wurde.)

Nur weil etwas besser ist, bricht man nicht unbedingt bestehende Konventionen. (Leider, muss man oftmals dazusagen.)

Lo!

[Deus Figendi]

Hallo,

Hallo Martin
und als erstes: Entschuldige, ich habe zwar alle Wortmeldungen hier zur Kenntnis genommen, aber versäumt dir zu antworten.

uraltes RFC (1982) welches in Abschnitt 5 Daten definiert:
date        =  1*2DIGIT month 2DIGIT
Das RFC sagt also klipp und klar: "Jahr" hat zwei Stellen!
das ist blöd, keine Frage. Ich mein, man hätte auch 1982 schon vorausschauend das Jahr vierstellig festlegen können;

Nah das will ich ihnen nachsehen, das Y2k-Problem stammt ja daher, dass damals halt auf jedes Bit geachtet wurde, 1982 war das noch relevant und zwei Stellen verbrauchen eben weniger Speicher als vier.
Das Problem war sicher absehbar, aber man hat vielleicht nicht gesehen, dass so alte Produkte (oder hier: Refferenzen) achtzehn Jahre später noch in Betrieb/Gebrauch sein würden.
Man hätte allerdings damals schon beides erlauben/vorstehen können das stimmt.
Wie gesagt ist sowas wahrscheinlich auf Speichermangel zurück zu führen, daher wunderte ich mich ja auch, dass man den Monat dann als drei Buchstaben angibt. Man braucht also (mindestens) 24 Bit um die drei Buchstaben zu schreiben (oder 21 geht glaube ich auch) oder acht Bit für ein word/shortint/byte oder sogar supersparsam vier Bit um zwölf verschiedene Zustände (Monate) abzulegen. Naja gut, eine Software, die diese Daten verwaltet kann intern natürlich mit vier Bit arbeiten.

In the wild habe ich ehrlich gesagt noch kein RSS-Feed gesehen, welches sich daran hält
Das heißt was? Setzen die das Jahr meist doch vierstellig ein?

Ja.

[ChrisB]

Hi,

Allerdings bezieht sich die Spezifikation an der Stelle auf ein uraltes RFC (1982) welches in Abschnitt 5 Daten definiert:
date        =  1*2DIGIT month 2DIGIT
Das RFC sagt also klipp und klar: "Jahr" hat zwei Stellen!

Dass schon das direkt dabeistehende Beispiel in dieser Spezifikation eine vierstellige Jahreszahl nutzt, sollte aber zu denken geben.

Das RFC sagt also klipp und klar: "Jahr" hat zwei Stellen!

http://cyber.law.harvard.edu/rss/rss.html#optionalChannelElements:
„All date-times in RSS conform to the Date and Time Specification of RFC 822, with the exception that the year may be expressed with two characters or four characters (four preferred).”

Als Ersteller eines RSS-Feeds würde ich auf jeden Fall das vierstellige Jahresformat nehmen.

In the wild habe ich ehrlich gesagt noch kein RSS-Feed gesehen, welches sich daran hält, aber es könnte ja sein. Die Frage ist: Wie gehe ich am Besten damit um?

Wer heutzutage noch ein zweistelliges Jahr angibt, muss damit rechnen, mißverstanden zu werden.

RDF Site Summary, the first version of RSS, was created by Guha at Netscape in March 1999 [Wikipedia]

Feeds, die wirklich aus einer Zeit vor dem Jahrtausendwechsel *stammen*, dürftest du damit wirklich kaum antreffen können.

Und wer in seinem Feed explizit Items ausliefern will, die aus Jahren < 2K stammen sollen, der sollte sich schon selber überlegt haben, dass es cleverer wäre, das Jahr dann vierstellig anzugeben.

Es hat sich ja ein bisschen eingebürgert, dass man Werte >1999 tendenziell eher vierstellig schreibt. Also _KÖNNTE_ ich annehmen dass zweistellige immer älter als 2k sind.
Andererseits geht es hier in der Regel um recht aktuelle Daten (rss => "News feed" also idR recht new) also _KÖNNTe_ ich ebenso annehmen, dass das Datum eher dazu tendiert recht jung zu sein.

Ich würde letzteres machen.
Das könnte zwar potentiell noch ein Mißverständnis sein, aber diese geringe Möglichkeit würde ich in Kauf nehmen.

MfG ChrisB

[Gunnar Bittersmann]

@@Deus Figendi:

nuqneH

Dritte Lösung (die mir beim Schreiben dieses Beitrags einfällt): Man könnte auch ein Stich-Datum machen an dem es sich scheidet. Am Ehesten böten sich wohl '50 (Mitte) oder '70 (Timestamp-Refferenz) an.

Oder die letzten zwei Stellen der aktuellen Jahreszahl. Feedeinträge werden ja kaum aus der Zukunft kommen.

Qapla'

[Alexander (HH)]

Moin Moin!

Dritte Lösung (die mir beim Schreiben dieses Beitrags einfällt): Man könnte auch ein Stich-Datum machen an dem es sich scheidet.

Das ist die gängige Praxis.

Oder die letzten zwei Stellen der aktuellen Jahreszahl. Feedeinträge werden ja kaum aus der Zukunft kommen.

Doch, das können sie. Naja, nicht wirklich, aber nicht alle Uhren sind synchronsiert. Rund um Silvester/Neujahr gibt es reichlich Gelegenheiten, bei denen zwei Rechner für einen begrenzten Zeitraum zwei verschiedene Jahre sehen, selbst wenn man das Zeitzonenproblem rausschummelt, indem man sich auf GMT oder UTC einigt.

Ein anderes Kriterium für zweistellige Jahre wäre ganz stumpf das Datum jeweiligen Spec bzw. das erste bekannte Dokument. RSS müßte so um 1999 sein, WWW ist von 1989.

Alexander