nicht angemeldet
9.9.99 ---» Probleme verursacht?
Hallo!
Aktuell zu diesem Datum wollte ich mal anfragen ob das Datum bei irgendwem Probleme verursacht hat? Weiss ist ein bisschen offtopic.
Wird ja bekannlich von Computern als Ende (9999) interpretiert.
Mfg Thomas!
-
Hallo Thomas
Aktuell zu diesem Datum wollte ich mal anfragen ob das Datum bei irgendwem Probleme verursacht hat? Weiss ist ein bisschen offtopic.
Denk einfach mal ein bischen aus Programmierersicht: selbst wenn jemand die 9er-Belegung in Datumsfeldern als Flag fuer Programmabbruch wegen Fehler oder dergleichen vorgesehen hat: dann wuerde es mit Sicherheit nicht die Belegung "9.9.99" sein, sondern die Belegung "99.99.99" - denn schliesslich sind tt und mm 2stellige Felder.
Allein schon deshalb gehoert das Gerede von diesem ganzen Zeugs ins Reich der Mythologie. Ganz abgesehen davon haben wir den 13.8. prima ueberstanden, also werden wir das heute auch noch packen <g>.
Auf diesem Wege meinen Glueckwunsch an den TeamOne-eigenen Taxifahrer Franz-Joseph und seine Anna, die heute einen Termin beim Standesamt Planegg ergattert haben!viele Gruesse
Stefan Muenz-
Denk einfach mal ein bischen aus Programmierersicht: selbst wenn jemand die 9er-Belegung in Datumsfeldern als Flag fuer Programmabbruch wegen Fehler oder dergleichen vorgesehen hat: dann wuerde es mit Sicherheit nicht die Belegung "9.9.99" sein, sondern die Belegung "99.99.99" - denn schliesslich sind tt und mm 2stellige Felder.
Hallo Stefan,
so ganz aus der Welt ist dieses Problem aber dennoch nicht, denn wenn man sich ein paar "alte" Großrechnerprogramme in Cobol, PL/I, ... anschaut, findet man doch öfter 9999 zum Setzen von Dateiendekennzeichen. Da z.B. Cobol in seiner Datenstruktur ein Feld Datum hat, daß sich aus datumjj, datumm, datumtt zusammensetzt und nun das heutige Datum 6-stellig dort einsetzt, kommt beim Auslesen 9999 raus, was beim Schreiben in eine Datei definitiv zu einem Fehler führt, wenn diese später wieder gelesen wird.
Im Normalfall passieren diese Zufälle nicht, aber es kann bei unorthodoxer Programmierung schon auftreten.Tschau, Stefan
-
hmmm, sollte da nicht 090999 raus werden?
also nur maximal drei 9er....wie sonst wird denn deiner meinung nach 21299 interpretiert?
ist das dann 21.2.99 oder 2.12.99?
denke 090999 sit wahrscheinlicher, oder?-
hmmm, sollte da nicht 090999 raus werden?
also nur maximal drei 9er....wie sonst wird denn deiner meinung nach 21299 interpretiert?
ist das dann 21.2.99 oder 2.12.99?
denke 090999 sit wahrscheinlicher, oder?Hallo,
ich habe mich mit COBOL zwar noch nicht sehr beschäftigt, aber dennoch habe ich dort schon mit Datum gearbeitet.
In den älteren Versionen von COBOL wurde 9999 ausgegeben, was natürlich blöd ist, weil COBOL das Datum in einer dynamischen Länge abspeichert. ist es der 9.9.99 wird 9999 ausgegeben. Allerdings setzte COBOL zur Weiterverarbeitung ein Bit, das anzeigte, welche Länge die einzelnen Abschnitte des Datums haben.
Die neueren Versionen von COBOL setzen auf die statische Länge von 6 Byte also 090999, so dass es da eigentlich keine Probleme geben dürfte.MfG Florian Auer
-
-
-
»» Ganz abgesehen davon haben wir den 13.8. prima ueberstanden, also werden wir das heute auch noch packen <g>.
War's nicht der 11.8.99 ?
<img src="http://www.BerlinOnline.de/wissen/berlin_fotos/.img/fotos/b120899.jpg" alt="">
Jedenfalls war's in Berlin so ;-)
viele Grüße
Beate Mielke
-
Hallo Beate
War's nicht der 11.8.99 ?
Am 11. war die Sofi, aber am 13. sollte die Welt untergehen. Wegen Freitag, Kometenschauer usw. Aber die Welt ist ja Gott sei dank nicht in Cobol programmiert, und jetzt geht's halt weiter ;-)
viele Gruesse
Stefan Muenz
-
-
Hallo Stefan!
Denk einfach mal ein bischen aus Programmierersicht: selbst wenn jemand die 9er-Belegung in Datumsfeldern als Flag fuer Programmabbruch wegen Fehler oder dergleichen vorgesehen hat: dann wuerde es mit Sicherheit nicht die Belegung "9.9.99" sein, sondern die Belegung "99.99.99" - denn schliesslich sind tt und mm 2stellige Felder.
Das klingt schon logisch. Man kann aber auch sagen, es ist voellig sinnlos, die Jahrhundertangabe wegzulassen, um Speicherplatz zu sparen (ich rede jetzt mal nicht von Cobol, wo das offenbar durch die Sprache vorgegeben ist, sondern nur von C). Kein vernuenftiger Programmierer wuerde auf die Idee kommen, ein Datum im Format YYMMDD oder so aehnlich *im Klartext*, also als ASCII-Zeichen zu speichern. Selbstverstaendlich wuerde man so etwas binaer speichern. Dann kann man naemlich 5 Bit fuer die Datumszahl reservieren und 4 Bit fuer die Monatszahl. Wenn man dann doch noch etwas verschwenderisch ist und alles in 32-Bit packt, bleiben 23 Bit fuer die Jahreszahl uebrig. Und mit 23 Bit lassen sich Zahlen bis ueber 8 Millionen darstellen. Und dann hat man trotzdem noch 2 Byte gespart (gegenueber den 6 Byte von YYMMDD).
Soweit die Theorie. Doch in der Praxis kann man nicht davon ausgehen, dass ein Programmierer vernuenftig ist. Meine Kollegen haben solche Source-Code-Scans gemacht, um Y2k-schwache Stellen zu finden. Und sie sagen: Wirklich jede Peinlichkeit, die man sich vorstellen kann, haben sich die Programmierer damals geleistet! Da erscheint die Sache mit zwei Stellen einsparen noch richtig vernueftig. In der Theorie hast Du vielleicht recht, aber keiner hat gesagt, dass diese "Programmierer" ihr Fach verstanden haben.
Calocybe
-
Hallo Calocybe
Meine Kollegen haben solche Source-Code-Scans gemacht, um Y2k-schwache Stellen zu finden. Und sie sagen: Wirklich jede Peinlichkeit, die man sich vorstellen kann, haben sich die Programmierer damals geleistet! Da erscheint die Sache mit zwei Stellen einsparen noch richtig vernueftig.
Aber sie beteuern es - etwa so: "Hotel, a former programmer, said he never coded September 9, 1999, without including zeroes, as in the string 090999" - dies und anderes ist uebrigens nachzulesen in dem Artikel http://cnn.com/TECH/computing/9909/08/9999.bug/
viele Gruesse
Stefan Muenz-
Moin Stefan!
Aber sie beteuern es [...]
Na ich will doch nicht sagen, dass damals alle Programmierer nur Bloedsinn gemacht haben. Aber ein paar (oder ein paar mehr) solche Helden gab's eben schon. Ist ja heute auch nicht anders. Oder hab ich jetzt falsch verstanden, was Du mir sagen wolltest? *unsicher sei*
Bye, Calo
-
Hallo Calocybe
Oder hab ich jetzt falsch verstanden, was Du mir sagen wolltest? *unsicher sei*
Ich hab zwar in letzter Zeit zu viel zwischen den Zeilen geredet, aber in diesem Fall hab ich nichts anderes sagen wollen als das was dasteht, also sei ganz beruhigt ;-)
viele Gruesse
Stefan Muenz
-
-
-
Das klingt schon logisch. Man kann aber auch sagen, es ist voellig sinnlos, die Jahrhundertangabe wegzulassen, um Speicherplatz zu sparen (ich rede jetzt mal nicht von Cobol, wo das offenbar durch die Sprache vorgegeben ist, sondern nur von C). Kein vernuenftiger Programmierer wuerde auf die Idee kommen, ein Datum im Format YYMMDD oder so aehnlich *im Klartext*, also als ASCII-Zeichen zu speichern. Selbstverstaendlich wuerde man so etwas binaer speichern. Dann kann man naemlich 5 Bit fuer die Datumszahl reservieren und 4 Bit fuer die Monatszahl. Wenn man dann doch noch etwas verschwenderisch ist und alles in 32-Bit packt, bleiben 23 Bit fuer die Jahreszahl uebrig. Und mit 23 Bit lassen sich Zahlen bis ueber 8 Millionen darstellen. Und dann hat man trotzdem noch 2 Byte gespart (gegenueber den 6 Byte von YYMMDD).
Oh, nicht wirklich: Kennst Du noch das IBM-Host-Format "Packed Decimal"?.
Damit kann man rechnen (es gibt separate Arithmetik-Maschinenbefehle dafür), aber auch die Konvertierung in einen anzeigbaren Ziffernstring gibt es als Maschinenbefehl. Keine komplizierte Konvertierungs-Routine!
(Das ist übrigens der Grund, weshalb Cobol solche Zahlen verwendete - weil es sie hardwaremäßig *gab* ...)
Und in diesem Format wird jede Ziffer in einem Halbbyte (16 Kombinationen) gespeichert - aber bei "99" ist Ende der Fahnenstange. Mit zwei Ziffern weniger hat man dabei immerhin doch ein *ganzes* Byte pro Datumsangabe eingespart ... (Boah, ey.)Das Schlimme ist, daß gerade *solche* Programme heute Probleme machen (die laufen noch auf den Hosts irgendwelcher Firmen, aber kaum jemand versteht die Materie mehr).
PC-Software ist ja so 'neu', daß es bei ihrer Erstellung schon 'genug' Hauptspeicher etc. gab - und der turnaround der Versionen ist auch viel schneller (DOS -> Windows, 16Bit -> 32Bit usw., während auf den Hosts ggf. noch 20-30 Jahre alte Programme laufen).-
Hi Michael
Oh, nicht wirklich: Kennst Du noch das IBM-Host-Format "Packed Decimal"?.
Du meinst BCD (binary coded decimal)? Naja, das gibt's bis auf den heutigen Tag in Intelprozessoren (andere CPUs kenne ich leider nicht). Und die RTC in einem jeden PC gibt die Zeit in diesem Format zurueck (ausser sie ist anders eingestellt).
Damit kann man rechnen (es gibt separate Arithmetik-Maschinenbefehle dafür), aber auch die Konvertierung in einen anzeigbaren Ziffernstring gibt es als Maschinenbefehl. Keine komplizierte Konvertierungs-Routine!
Eben. Die Befehle hiessen wohl AAD und AAM (hab nie mit BCDs gerechnet, nur davon gelesen). Eigentlich dienen sie zum Vorbereiten einer BCD-Division / Fertigstellen einer BCD-Multiplikation; was sie letztlich wirklich gemacht haben, war die BCDs in Binaerzahlen umzuwandeln und umgekehrt. Gerade wo es diese Moeglichkeiten nun schon gab, war es doch recht einfach, Zahlen binaer zu speichern und in BCD zu verarbeiten, oder?
Und in diesem Format wird jede Ziffer in einem Halbbyte (16 Kombinationen) gespeichert - aber bei "99" ist Ende der Fahnenstange.
Das sind uebrigens die ungepackten BCDs. Bei gepackten BCDs hat man zwei Ziffern in ein Halbbyte gesteckt, fuer jede Ziffer also nur 4 Bit verwendet.
PC-Software ist ja so 'neu', daß es bei ihrer Erstellung schon 'genug' Hauptspeicher etc. gab - und der turnaround der Versionen ist auch viel schneller (DOS -> Windows, 16Bit -> 32Bit usw., während auf den Hosts ggf. noch 20-30 Jahre alte Programme laufen).
Was ich so schlimm finde ist, dass jetzt jeder denkt, RAM gibt's sowieso ohne Ende, da braucht man sich keine Gedanken drum machen. Kein Wunder, dass heutzutage 64 MB als absolutes Minimum angesehen werden. Wuerden sich die Programmierer etwas mehr Muehe geben, koennte man ohne Probleme auch mit max. 32 MB gut arbeiten.
Calocybe
-
Oh, nicht wirklich: Kennst Du noch das IBM-Host-Format "Packed Decimal"?.
Du meinst BCD (binary coded decimal)? Naja, das gibt's bis auf den heutigen Tag in Intelprozessoren (andere CPUs kenne ich leider nicht). Und die RTC in einem jeden PC gibt die Zeit in diesem Format zurueck (ausser sie ist anders eingestellt).Ich glaube, das, was ich meine, ist so alt, da gab es Intel noch gar nicht. ;-)
Aber es könnte wirklich BCD heißen. (Die IBM-370-Befehle zum Ein- und Auspacken hießen irgendwie PACK und UNPACK oder so ähnlich - das ist schon ein paar Jahrzehnte her ... ;-)Und in diesem Format wird jede Ziffer in einem Halbbyte (16 Kombinationen) gespeichert - aber bei "99" ist Ende der Fahnenstange.
Das sind uebrigens die ungepackten BCDs. Bei gepackten BCDs hat man zwei Ziffern in ein Halbbyte gesteckt, fuer jede Ziffer also nur 4 Bit verwendet.Lies Dir diesen Absatz noch mal sorgfältig durch ... wieviele Bit hat ein Halbbyte? ;-)))
Was ich so schlimm finde ist, dass jetzt jeder denkt, RAM gibt's sowieso ohne Ende, da braucht man sich keine Gedanken drum machen. Kein Wunder, dass heutzutage 64 MB als absolutes Minimum angesehen werden. Wuerden sich die Programmierer etwas mehr Muehe geben, koennte man ohne Probleme auch mit max. 32 MB gut arbeiten.
Aber dann würde Window fünfmal so viel kosten - in der Summe wäre es jedenfalls nicht billiger.
RAM-Chips kann man maschinell fertigen - Betriebssysteme nicht. (Obwohl man manchmal den Eindruck gewinnen könnte ... hm ... ;-)-
Hi!
Lies Dir diesen Absatz noch mal sorgfältig durch ... wieviele Bit hat ein Halbbyte? ;-)))
*boing* *rotwerd* Ist ja peinlich! *g* Na dann waren das ja schon die gepackten BCDs.
RAM-Chips kann man maschinell fertigen - Betriebssysteme nicht. (Obwohl man manchmal den Eindruck gewinnen könnte ... hm ... ;-)
Ach jetzt weiss ich's, die Microsoftrmannschaft ist bloss ein Haufen von Cyborgs, die die Weltherrschaft uebernehmen wollen... Ja, das passt irgendwie. *g*
Calocybe
-
-
-
-
-
-
http://www.heise.de/newsticker/data/cp-09.09.99-002/