Hallo, vor etwas mehr als 10 Jahren sprach man überall von dem Jahr 2000 Problem und es passierte (sogut wie) nichts. Heute haben wir das Jahr 2010 Problem, was uns doch etwas überraschend getroffen hat. Man liest oft die Meldungen, dass die Systeme denken, es wäre das Jahr 2016. Weiß von euch jemand, woher so etwas kommt oder was es mit der Jahreszahl aufsich hat?
Gast
#1542953
Da hat sich 'ne gwiefte BWL-Nase einen Bonus verdient, das Geld über die Feiertage bei den Banken zu lassen und damit zu arbeiten. - Feiertage: Kundschaft ist nachsichtig - Pressemeldungen gezielt streuen - Software einspielen. Soweit meine Verschwörungstheorie zum Thema EC-Karten-2010-Problem. ;-)
Hat da jemand ein BCD-Feld für die beiden letzten Stellen der Jahreszahl binär interpretiert?
Hi das liegt (teilweise) garantiert an der "$%"§$%"§ BCD-Zählweise diverser RTC-Chips. Ich hab nie verstanden warum neue RTCs zum Teil immer noch in BCD zählen. Matthias
der vorteil von bcd hat sich mir auch noch nie erschlossen. Immer diese Scheißumrechnung mit divisionen durch die binär schiefe 10
und mir erschließt sich nicht, warum man im Jahr 2010 (Zweitausendundzehn) Jahreszahlen abkürzt zu 10. Diese permanente Umrechnungs- und Konvertierungskacke ist doch 100 mal fehleranfälliger und aufwändiger, als da direkt 4-stellige Jahreszahlen zu verwenden. Das ist dann zwar EINMAL aufwändig, aber reicht dann noch die nächsten ca. 8000 Jahre. Das erinnert mich irgendwie ziemlich an dieses Festplatten-Kapazitäts-Gefusche von MS.
Vlad Tepesch schrieb: > der vorteil von bcd hat sich mir auch noch nie erschlossen. Diese Darstellung ist für die Hirne von Cobol-Programmierern optimiert. Aber Spaß bei Seite: wenn man nur mit irgend welchen Logikchips rumfrickelt und dann das Ergebnis auf irgend welche 7-Segment-Displays schicken muß, dann BCD durchaus seine Berechtigung. Im µC-Zeitalter ist es aber in der Tat etwas antiquiert. Wegstaben Verbuchsler schrieb: > Das erinnert mich irgendwie ziemlich an dieses > Festplatten-Kapazitäts-Gefusche von MS. Aus dieser Richtung weht der Wind... Aber es gibt auch in Prozessoren eine sinnvolle Anwendung: Wenn genaue Artihmetiken impementiert werden sollen, arbeitet man gerne mit BCD-Darstellungen. Das hat den Vorteil, daß die Binär/Dezimalwandlung wegfällt und damit die Fehler die dabei auftreten können.
Uhu Uhuhu schrieb: > Aber Spaß bei Seite: wenn man nur mit irgend welchen Logikchips > rumfrickelt und dann das Ergebnis auf irgend welche 7-Segment-Displays > schicken muß, dann BCD durchaus seine Berechtigung. Da brauch ich für die Ausgabe einen bin2bcd decoder, ja, aber deswegen intern alles in bcd zu halten ist meiner Meinung nach Quatsch Wegstaben Verbuchsler schrieb: > Das erinnert mich irgendwie ziemlich an dieses > Festplatten-Kapazitäts-Gefusche von MS. Was meinst du damit? das ein kB = 1024 Byte sind hat mit M$ nichts zu tun. witzigerweise haben die Händler und Festplattenhersteller aber mit 1kB=1000B eher Recht, da vor einiger Zeit festegelegt wurde, dass wegen der herrschenden Verwirrung die SI-Abkürzungen auch für die SI-Multiplikatoren stehen. für die Binärsachen wurden Gibi, Mebi, Kibi, ... eingeführt, was aber keiner benutzt, da es sich schwul anhört
Uhu Uhuhu schrieb: > Aber es gibt auch in Prozessoren eine sinnvolle Anwendung: Wenn genaue > Artihmetiken impementiert werden sollen, arbeitet man gerne mit > BCD-Darstellungen. Das hat den Vorteil, daß die Binär/Dezimalwandlung > wegfällt und damit die Fehler die dabei auftreten können. das macht das ganze aber nicht effektiver, da man selbst ständig auf überläufe testen und den Carry kompliziert handlen muss. Desweiteren treten die selben Fehler auf, da der Fehler nicht von der Zahlenbasis abhängt sondern von der Anzahl der zur Verfügung stehenden Speicherzellen. Bei BCD verschwendet man ja noch platz, was dazu führt, dass eine BCD Zahl mit gleichem Speicherverbrach ungenauer ssit, als eine direkt in Binärdarstellung.
>> Wegstaben Verbuchsler schrieb: >> Das erinnert mich irgendwie ziemlich an dieses >> Festplatten-Kapazitäts-Gefusche von MS. > Was meinst du damit? > das ein kB = 1024 Byte sind hat mit M$ nichts zu tun. Das nicht. Das "Festplatten-Gepfusche" bestand/besteht darin, daß die ersten Platten "damals" (tm) eine mickrige Kapazität hatten (10-40 Mega-Byte). Also wurden Partitionstabellen, Controller und Dateisysteme auf "mickrige" Größen ausgelegt und erst "nach und nach" aufgebohrt (FAT12, FAT16, FAT32 etc, wobei FAT32 selbst nur zögerlich von M$ unterstützt wurde. Bei den ersten Varianten vom NTFS gab es doch meienr Erinenrnung nach auch solch ein Gehampel. Dann gabs also als Konsequenz da bei den Festplatten eine 540 MB-Grenze, dann eine 2,irgendwas Grenze, dann noch eine Grenze etc. Immer weil irgendwelche Pfuschereien verhinderten, direkt mal sinnvolle Größen zu verwenden. Und wenn, dann wurde zuerst mal der "Blocking-FAktor" auf aberwitzige Größen eingestellt (32 oder 64 KByte), um zumindest mit dem vorhandenen Dateisystem "irgendwie" noch die "riesigen" Plattenkapazitäten nutzbar zu machen. Selbst heute gelten dann noch irgendwelche merkwürdigen Einschränkungen der Form "MS-Windows Version xx darf nur in der 1. Partition innerhalb der ersten xx Sektoren liegen, sonst geht dies oder das nicht". Halt alles ein riesengroßer Pfusch. Das sowas auch besser geht, wenn man von vorneherein durchgängig 32 bit oder 64 bit für Blockadressierungen verwendet, wissen wir beide, und da gibt es genügend positive Gegenbeispiele. Daß es mit der Jahreszahl-"Berechnungen" auch besser geht, wenn konsequent JEDES Stückchen Hardware und Software auf 4-stellige Jahreszahlen "umgebaut" wird (zumindest neues Zeugs), ist dann die logische Brücke zu meinen Aussagen bzw. zum Vergleich mit M$-Kapazitäts-Pfusch.
ahh, danke für die Erläuterung. Aber Speicher ist doch teuer ;-)
Die geschilderten "Pfuschereien" sind zwar welche, gehen aber nicht auf das Konto von Microsoft. Die haben weder den PC erfunden, noch spezifiziert, wie mit Festplatten umzugehen ist. Die unterschiedlichen Grenzen der Plattengrößen sind IBM bzw. den nachfolgenden BIOS-Schreiberlingen zu verdanken, und den nicht ausreichend weitsichtigen Menschen, die aufbauend auf dem Festplattencontroller des IBM AT die IDE-Spezifikation entwickelten. Die saßen auch bei IBM. NTFS hatte übrigens selbst kein "Gehampel", das "Gehampel" entstand durch den unfähigen Installations-Mechanismus von alten NT-Versionen, die nur auf eine FAT16-Partition installieren konnten, die erst danach in eine NTFS-Partition umgewandelt wurde. Daraus resultierten maximal 4 GB Partitionsgröße (FAT16 mit 64 kiB-Clustern); hat man so ein System mit einem Festplattenimager kopiert, konnten durchaus ganz andere Partitionsgrößen verwendet werden. Sofern das BIOS des Rechners mit der jeweiligen Festplattengröße klarkam, was z.B. bei SCSI-Platten nie ein Problem war, da da nicht das PC-BIOS, sondern die BIOS-Erweiterung des SCSI-Controllers genutzt wurde, und SCSI schon immer mit Blockadressen arbeitet. MS hat viel Schund verbrochen, aber das hat der Verein tatsächlich mal nicht zu verantworten.
Rufus t. Firefly schrieb: > Die geschilderten "Pfuschereien" sind zwar welche, gehen aber nicht auf > das Konto von Microsoft. Stimmt, die gehen größtenteils auf IBM und ihr BIOS zurück, das Festplatten nach physischen Parametern statt von vornherein gleich nach logischen Blöcken verwaltet hat. Der Anschluss einer Platte, die in logischen Blöcken arbeitet (SCSI hat das schon immer so gemacht) an ein so verkrückt spezifiziertes BIOS war entsprechend ein Krampf. Das ATA-Standard-Konsortium war aber auch schon immer für viel Spaß gut. Am besten gefällt mir seit Jahren dieses Zitat aus dem ATA- Standard:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Was zum Geier[tm] soll man als Implementierer mit so einem Unfug anfangen? "may be valid"? "may be standard"? The "may be" standard.
Jörg Wunsch schrieb:
>1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
> > Was zum Geier[tm] soll man als Implementierer mit so einem Unfug > anfangen? "may be valid"? "may be standard"? The "may be" > standard. 1) Für die alltägliche Arbeit ignorieren 2) Ein Tuning Tool schreiben was diese "geheimen Spezialparamter für den Ambitionierten Gamer/Hacker/Tuner" anzeigen kann und als Addon für einen ordenlichen Aufschlag verkaufen ;)
Und wenn man mal SCSI und ATA auf der Protokollebene vergleicht kann man auch leicht feststellen, wer von wem abgekupfert hat. :-)
hmm...kann nochmal jemand anhand eines beispiels genauer erklären, wie das 2010-problem entstanden ist? wieso führt die bcd-interpretation dazu, dass 2010 als 2016 verstanden wird?? das ist mir ehrlich gesagt alles noch etwas schleierhaft - über eine ausführlichere erklärung würde ich mich sehr freuen :-) VG, mui
> Selbst heute gelten dann noch irgendwelche merkwürdigen Einschränkungen > der Form "MS-Windows Version xx darf nur in der 1. Partition innerhalb > der ersten xx Sektoren liegen, sonst geht dies oder das nicht". Ich will die Jungs und Mädels die das verbrochen haben jetzt nicht in Schutz nehmen, aber in Zeiten in denen jedes Quartal mit möglichst hohem Gewinn abgeschlossen werden muss, bleibt schlussendlich auch den Entwicklern keine Zeit mehr, die optimale Lösung auszubrüten. Meiner Meinung nach sind also auch Investoren, Aktionäre und schlussendlich die Kunden im Geschäft schuld, die ja nicht zu viel ausgeben wollen.
da ist nichts schleierhaft jahreszahlen werden nach tradierter weise in 2 halbbyte(nibble) gespeichert (ohne hunderter und tausender) dezimal 1 0 BCD 1 0 10 + 0 = 10 binär interpretiert 1 0 = 16 + 0 = 16
bis neun geht das gut, da die erste stelle in Beiden fällen 0 ist binä würde die 10 jedoch so aussehen: 10 bin: 0x0A 10 bcd: 0x10 und erst bei der 16 das 1. Bit des zweiten Nibbles gesetzt werden: 16 bin: 0x10 16 bcd: 0x16
Vlad Tepesch schrieb: > Da brauch ich für die Ausgabe einen bin2bcd decoder, ja, aber deswegen > intern alles in bcd zu halten ist meiner Meinung nach Quatsch Und wie machst du das, wenn du z.B. 6 Dezimalstellen darstellen willst - das sind 20 Bit rein Binär - ohne µC und nur mit irgend welchen Logikchips ist das ganz schön aufwendig. Vlad Tepesch schrieb: >> Aber es gibt auch in Prozessoren eine sinnvolle Anwendung: Wenn genaue >> Artihmetiken impementiert werden sollen, arbeitet man gerne mit >> BCD-Darstellungen. Das hat den Vorteil, daß die Binär/Dezimalwandlung >> wegfällt und damit die Fehler die dabei auftreten können. > > das macht das ganze aber nicht effektiver, da man selbst ständig auf > überläufe testen und den Carry kompliziert handlen muss. Es ist nicht so wahnsinnig viel ineffektiver, denn viele Prozessoren unterstützen BCD-Artihmetik hardwaremäßig. Die haben dann im Stusregister noch ein spezielles Hilfs-Carry, bei den 8080 und Z80 heißt das z.B. AC. Für die Arithmetik werden die normalen Binärbefehle verwendet, nach jeder Operation muß noch ein Korrekturbefehl ausgeführt werden - beim Z80 heißt der DAA: Decimal Adjust Accumulator. Benutzt wird BCD-Arithmetik z.B. von Pascal-SC - da kommt es weniger auf Geschwindigkeit, als auf Genauigkeit an.
Hannes H. schrieb: > wieso führt die bcd-interpretation > dazu, dass 2010 als 2016 verstanden wird?? Das ist eigentlich nur eine Ausprägung einer ganzen Klasse von Fehlern: der Fehlinterpretation von Bitmustern. Die Typisierung der Programmiersprachen wurde entwickelt, um dieses Elend zu bekämpfen. Zum aktuellen Problem: Der Fehler kann nur zunächst unentdeckt bleiben, wenn nur 2 Stellen der Jahreszahl gespeichert werden - dann sind die Ziffern 0 - 9 für BCD- und Binär-Darstellung identisch. Ab Dezimal 10 unterscheiden sie sich um 6. Wenn nun ein Programmierer nicht aufpaßt und die eigentlich BCD-codierte Zahl binär interpretiert, dann ist es passiert...
Gast
#1543554
Dann sollte das Problem schon vor dem Jahr 2000 erkannt worden sein. Ich bleibe dabei: das war Absicht! ;-)
Thilo, lediglich du warst Absicht!
Gast
#1543565
Uhu Uhuhu schrieb:
> Thilo, lediglich du warst Absicht!
Ja, und zwar in böswilliger Absicht Uhus zu ärgern. :)
Du musst es wissen ...
Oh das da noch keiner draf gekommen ist? Aber vielleicht hast du ja recht und ein Nichteuropäer hat die Möglichkeit genutzt Chaos in Oldeurop zu stiften. ;-)
Uhu Uhuhu schrieb: > Die haben dann im > Stusregister noch ein spezielles Hilfs-Carry, bei den 8080 und Z80 heißt > das z.B. AC. Hieß das nicht beim Z80 "H" (half-carry)?
wäre aber nicht das gleiche
Jörg Wunsch schrieb:
> Hieß das nicht beim Z80 "H" (half-carry)?
Stimmt - möglicherweise hieß es beim 8080 so.
Uhu Uhuhu schrieb: > Es ist nicht so wahnsinnig viel ineffektiver, denn viele Prozessoren > unterstützen BCD-Artihmetik hardwaremäßig. Die haben dann im > Stusregister noch ein spezielles Hilfs-Carry, bei den 8080 und Z80 heißt > das z.B. AC. > > Für die Arithmetik werden die normalen Binärbefehle verwendet, nach > jeder Operation muß noch ein Korrekturbefehl ausgeführt werden - beim > Z80 heißt der DAA: Decimal Adjust Accumulator. wieder was gelernt Die Processoren die ich bisher in ASM kennengelernt habe hatten das nicht. (beim x86 weiß ichs nicht mehr) > > Benutzt wird BCD-Arithmetik z.B. von Pascal-SC - da kommt es weniger auf > Geschwindigkeit, als auf Genauigkeit an. wie gesagt: wo soll es denn genauer werden? für die gleiche Gneauigkeit brauchst du bei BCD mehr Speicher
Z.B. wenn du Fließkommaformate hast, dann ist die Dezimal <-> Binär-Wandlung Rundungsfehlerbehaftet. Diese Fehler bekommt man nicht, wenn man mit BCD rechnet.
Thilo M. schrieb:
> Dann sollte das Problem schon vor dem Jahr 2000 erkannt worden sein.
Aber nicht bei Produkten die erst nach dem 31.12.1999
entwickelt/verkauft/eingesetzt wurden.
Matthias
Vlad Tepesch schrieb:
> für die gleiche Gneauigkeit brauchst du bei BCD mehr Speicher
Das Argument spielt heute keine Rolle mehr.
Uhu Uhuhu schrieb: > Zum aktuellen Problem: > Der Fehler kann nur zunächst unentdeckt bleiben, wenn nur 2 Stellen der > Jahreszahl gespeichert werden - dann sind die Ziffern 0 - 9 für BCD- und > Binär-Darstellung identisch. Ab Dezimal 10 unterscheiden sie sich um 6. > > Wenn nun ein Programmierer nicht aufpaßt und die eigentlich BCD-codierte > Zahl binär interpretiert, dann ist es passiert... aber wie kann denn sowas passieren?! die interpretation von "99" aus dem jahr 1999 muss ja auch schon bcd-basiert gewesen sein - sonst wäre doch, wie weiter oben schon erwähnt, das ganze schon früher aufgefallen...und nach der jahrtausendwende war den programmierern nicht bewusst, dass das datum im bcd-format dargestellt wird?! gibt es eigentlich irgendwo eine offizielle, etwas technischere aussage zu dem Problem außer: "es gibt einen fehler bei der verarbeitung des datums"? irgendwo hatte ich gelesen, dass die verwechslung von dezimal und hexadezimaldarstellung angeblich NICHT das problem sein soll...leider finde ich den link zu der quelle nicht mehr....
Hannes H. schrieb: > aber wie kann denn sowas passieren?! die interpretation von "99" aus dem > jahr 1999 muss ja auch schon bcd-basiert gewesen Das Programm wird erst nach 2000 entwickelt worden sein. Fehler passieren immer. Schlimm werden sie halt, wenn der Hersteller keine, oder nur eine schlampige Qualitätskontrolle durführt. Jeder einigermaßen gewiefte Testingenieur müßte auf derlei Fehlermöglichkeiten geradezu geeicht sein... Daß man da jemals eine "offizielle" Beschreibung bekommen wird, halte ich für unwahrscheinlich - es wird schließlich um einen Riesenschaden gestritten werden...
Hannes H. schrieb: >> Wenn nun ein Programmierer nicht aufpaßt und die eigentlich BCD-codierte >> Zahl binär interpretiert, dann ist es passiert... > > aber wie kann denn sowas passieren?! <ironie on> indem man richtige Programmierer rauswirft und die billigeren VBA Programmierer einstellt <ironie off>
Karl heinz Buchegger schrieb: >> aber wie kann denn sowas passieren?! > > <ironie on> > indem man richtige Programmierer rauswirft und die > billigeren VBA Programmierer einstellt > <ironie off> okay, war mehr eine rhetorische frage - soo naiv bin ich dann doch nicht ;-) sowas SOLLTE natürlich nicht passieren, ist aber kein wunder wenn alles schnell und billig umgesetzt werden muss, sich ein entwickler nur jeweils fünf minuten auf seine zwanzig von ihm bearbeiteten projekte konzentrieren kann und dabei zwischendurch noch ständig unterbrochen wird - dass dann sowas dabei rauskommt verwundert eigentlich nicht. der test wird dann am kunden durchgeführt...
http://www.heise.de/security/meldung/Desaster-mit-EC-Karten-kann-teuer-werden-896988.html http://www.spiegel.de/wirtschaft/unternehmen/0,1518,670400,00.html
Hat wohl einer die Spec der altsystem nicht richtig gelesen oder der alte Programmierer des COBOL Systems ist inzwischen verstorben ;-) Aber mir ist immer noch Schleierhaft was BCD für einen Vorteil gegenüber einer Fixkomma Binärzahl haben soll. Nach der 2000 Panik ist aber echt unverständlich wieso ein Testteam nicht mindestens die nächsten 100 Jahre durchlaufen ließ. Kreditkarten gehen ja schlauerweis auf 4 stellige Jahreszahlen über. Tom
Thomas Burkhart schrieb:
> Kreditkarten gehen ja schlauerweis auf 4 stellige Jahreszahlen über.
Ich habe noch nie die Magnetspur meiner Kreditkarten ausgelesen, aber
auf der Karte selbst steht die Jahreszahl immer noch zweistellig.
Allerdings ist es auch kein Problem, da die Karte oder das Lesegerät
"dumm" sind. Die Kartendaten werden komplett an die Bank übertragen und
die sagt dann, ob der Umsatz akzeptiert wird oder nicht.
Zumindest ist mir aufgefallen, dass immer mehr Onlineshops die Jahreszahl der Kreditkarte 4-Stellig abfragen.
Sorry, aber ich kenne keinen einzigen Shop, der die Vierstellig abfragt. In der Regel wird eh in dem Format MMYY abgefragt.
Erst gestern flybe.com & paypal, aber auch andere und es werden mehr.
Hmm... okay... bisher ist mir das noch nie aufgefallen. Aber ich frage mich, was es bringt? Ich habe grade in der Spezi nachgelesen, das Gültigkeitsdatum steht auf der Spur 2 in dem Format MMYY, wie ich bereits gesagt habe.
gerade auf n-tv gezeigt: die Händler haben mittlerweile eine Trick gefunden, wie man die Karten wieder benützen kann - Man klebt den Chip mit einem Streifen Tesa ab!!! Wenn die Kartenlesegeräte den Sicherheitschip nicht mehr auslesen können, greifen sie auf den Magnetstreifen zurück! DAS ist sicherlich auch nicht die Funktion eines SICHERHEITSchips, dass er sich, mit Tesa überklebt, einfach ausser Kraft setzen lässt!? Video auf der rechten Seite:"Trick für EC-Karten" http://www.n-tv.de/ratgeber/Was-Kunden-wissen-muessen-article667222.html
Thomas Burkhart schrieb: > Hat wohl einer die Spec der altsystem nicht richtig gelesen oder der > alte Programmierer des COBOL Systems ist inzwischen verstorben ;-) > > Aber mir ist immer noch Schleierhaft was BCD für einen Vorteil gegenüber > einer Fixkomma Binärzahl haben soll. > Da kann ich Dir helfen: Der wesentliche Vorteil ist, dass BCD-Zahlen bei der Ein- und Ausgabe keinerlei Rundungsfehler produzieren. Vorlesung Infofmatik für E-Techniker, 1. Semester. Das ist wahrscheinlich auch der Grund warum besonders im Bankenbereich immer noch COBOL verwendet wird...
Die Rundungsfehler hast Du bei ner Fixkomma Binärzahl doch auch nicht. Gruß Tom
Thomas Burkhart schrieb: > Die Rundungsfehler hast Du bei ner Fixkomma Binärzahl doch auch nicht. > > Gruß > Tom Ja, hast Recht.
Thomas Burkhart schrieb: > Die Rundungsfehler hast Du bei ner Fixkomma Binärzahl doch auch nicht. > Eben. Sei es wie es sei. Da sind Leute am Werk, deren denken kreist immer noch um Eingabemasken, wei man sie in den 60-er/70-er Jahren hatte. Auf der Maske hat man 2 bzw. 4 Eingabepositionen, also muss auch der Datensatz an dieser Stelle 2 bzw. 4 'Bytes' dafür haben.
Thomas Burkhart schrieb:
> Die Rundungsfehler hast Du bei ner Fixkomma Binärzahl doch auch nicht.
Dann schau dir mal an, wie viele Stellen du brauchst, um 0,01 (1 Cent)
binär als Festkommazahl darzustellen.
Jörg Wunsch schrieb: > Dann schau dir mal an, wie viele Stellen du brauchst, um 0,01 (1 Cent) > binär als Festkommazahl darzustellen. Wir haben heute aber die Bandbreite, wir haben auch den Speicher(platz). Was heute nicht funktioniert, ist die strikte Einhaltung von Standards. IEEE 754 FTW. Und mal ganz ehrlich: eine Sieben-Segment-Anzeige habe ich das letzte Mal in der Schule verwendet. Jedes Popel-Device bekommt heute schon fast ein OLED Display.
Dimitri Roschkowski schrieb: > Jörg Wunsch schrieb: >> Dann schau dir mal an, wie viele Stellen du brauchst, um 0,01 (1 Cent) >> binär als Festkommazahl darzustellen. > > Wir haben heute aber die Bandbreite, wir haben auch den Speicher(platz). > Was heute nicht funktioniert, ist die strikte Einhaltung von Standards. > IEEE 754 FTW. Und mal ganz ehrlich: eine Sieben-Segment-Anzeige habe ich > das letzte Mal in der Schule verwendet. Jedes Popel-Device bekommt heute > schon fast ein OLED Display. Es soll ja auch schon Telefone ohne Tasten geben... Die interne BCD-Darstellung und die zugehörigen Rechenroutinen haben ihre Berechtigung da, wo es um Genauigkeit geht. Das hat mit LCD oder noch moderneren E/A-Medien überhaupt nichts zu tun. Dem Medium ist es nämlich egal welche Daten es anzeigt. Falsche Datenanzeige soll es sogar gelegentlich auf Windows-Bildschirmen geben. Auf dem Kontoauszug Deiner Bank aber?
Gast
#1544955
Es gibt keinen wirklichen Vorteil bei BCDs. Ausser bei: * Umwandlung von/zu string (denn die Änderung der Basis entfällt) * Beliebig lange Zahlen, egal ob Integer oder Fest/Fließ-komma Grad letzteres kann manchmal sehr interessant sein, wenn man eine lib hat die diese BCDs mit einem Längenangabe-Feld verarbeiten kann. Dadurch kann man z.B. rationale Zahlen weitaus genauer darstellen und halten. Genau das ist bei Finanzmathematik interessant. Ihr könnt euch garnicht vorstellen wie die Leute ausflippen wenn bei aufaddierten Teilbeträgen und einer Endsumme von paar Millionen € 1 Cent Differenz ist. Gruß, Nick
Seltsam an der ganzen Sache find ich nur: >Die von Gemalto für andere Länder produzierten Karten sollen indes nicht >betroffen sein. Haben die tatsächlich nur für deutsche Banken 'n eigenen Chip gebastelt? Warum?
Gerry E. schrieb: > Die interne BCD-Darstellung und die zugehörigen Rechenroutinen haben > ihre Berechtigung da, wo es um Genauigkeit geht. Ich bin ganz ehrlich, ich glaube nicht, dass BCD genauer ist, als eine 64/128 Bit IEEE Gleitkommazahl. Dafür sind meine Rechenoperationen mit BCD aufwändiger.
Karl heinz Buchegger schrieb: > Da sind Leute am Werk, deren denken kreist immer noch > um Eingabemasken, wei man sie in den 60-er/70-er Jahren hatte. Alt, aber bezahlt. Gilt auch für Software. Eine gewisse Konservativität in solchen Dingen resultiert einfach aus der Überlegung, daß man möglichst wenig ändern sollte, um nicht plötzlich mit Kompatibilitätsproblemen konfrontiert zu sein, die man nicht erwartet hat. In der richtigen Wirtschaft stehen eben nicht überall auf einen Schlag die neusten Geräte bereit...
Uhu Uhuhu schrieb: > In der richtigen Wirtschaft stehen eben nicht überall auf einen Schlag > die neusten Geräte bereit... Genau deshalb verdient sich jetzt einer meiner Kumpel eine goldene Nase, weil er die Uralt-Mainframes, die ein ganzes RZ gefüllt haben, auf 1HE Server mit einer VM umstellt.
Ändere nie ein laufendes System. (Alte Elektrikerweisheit) ;-) MfG Paul
Dimitri Roschkowski schrieb: > Gerry E. schrieb: >> Die interne BCD-Darstellung und die zugehörigen Rechenroutinen haben >> ihre Berechtigung da, wo es um Genauigkeit geht. > > Ich bin ganz ehrlich, ich glaube nicht, dass BCD genauer ist, als eine > 64/128 Bit IEEE Gleitkommazahl. Im kaufmännischen Bereich schon. Siehe zb das Problem, dass im Binärsystem viele Zahlen eine unendliche Periode haben, die aber in der Praxis keineswegs esoterisch sondern gang und gäbe sind. So ist zb 0.1 schon nicht mehr exakt in deinem IEEE Format darstellbar. Und 10 Cent kommen dann schon mal vor. Du kannst ja einmal folgendes Programm laufen lassen und nachsehen ob bei dir die erwartete Ausgabe kommt
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Auf meinem PC wird der Text nie ausgegeben, obwohl die Mathe sagt, dass j irgendwann 2 sein muss. > Dafür sind meine Rechenoperationen mit > BCD aufwändiger. Spielt bei kaufmännischen Operationen weniger die Rolle. Das Gros der Berechnungen sind Additionen.
Paul Baumann schrieb:
> Ändere nie ein laufendes System.
Das ist schwierig, wenn man die letzte 100MB Festplatte in der Größe
eines Schuhkartons in den Server einbaut.
Dimitri Roschkowski schrieb: > Ich bin ganz ehrlich, ich glaube nicht, dass BCD genauer ist, als eine > 64/128 Bit IEEE Gleitkommazahl. Dafür sind meine Rechenoperationen mit > BCD aufwändiger. Glauben heißt, nicht wissen. Bei der Wandlung von binären Fließkommaformaten in die Dezimaldarstellung und zurück können Rundungsfehler auftreten, die bei der eigentlichen Rechnung nicht entstehen. Ursache ist, daß nicht alle gebrochenen Werte in jedem Zahlensystem eine endliche Darstellung haben. Außerdem ist die Genauigkeit von Gleitkommazahlen durch ihre Mantissenlänge bestimmt und es ist für die meisten Anwendungen kein Problem, eine BDC-Darstellung zu kreieren, die einen ausreichend großen Bereich umfaßt und jedes Gleitkommaformat an Genauigkeit übertrifft. Die Pathologie der Gleitkommazahlen beginnt, wenn man sehr große mit sehr kleinen Zahlen verrechnet - das kann so weit gehen, daß das Ergebnis völliger Unsinn ist.
Dimitri Roschkowski schrieb: > Das ist schwierig, wenn man die letzte 100MB Festplatte in der Größe > eines Schuhkartons in den Server einbaut. Ich habe mal auf einer Maschine gearbeitet, die hatte als Massenspeicher eine 40 MB Festkopfplatte. Die hatte das Format eines Kleiderschrankes.
Das Lustige in unserer Gesellschaft ist, dass es immer die selben Berufsgruppen trifft. Vor einem Jahr die Bankenkrise, jetzt gehen die Karten nicht mehr. Man erkennt mit welcher Rücksicht die entsprechenden Gruppen arbeiten. Ich habe noch nie gehört, das bei einem Jahreswechel, bei der Lufthansa die Triebwerke ausgehen!!!!! Naja, - vielleicht wisses Sie um Ihre Verantwortung dem Kunden gegenüber!!!! Was man von unseren Bänkern nicht sagen kann!!! - Ja macht nur weiter so (ihr seid die besten!!)!!!! LG Klaus
Uhu Uhuhu schrieb: > Die Pathologie der Gleitkommazahlen beginnt, wenn man sehr große mit > sehr kleinen Zahlen verrechnet Oder entsprechend viele Operationen macht. > - das kann so weit gehen, daß das > Ergebnis völliger Unsinn ist. Yup. Hatte ich mal. Der simulierte Roboter am Schirm hat sich vor den Augen des Chefs in Einzelteile aufgelöst, weil sich die Ungenauigkeiten in den Matrizenoperationen aufsummiert haben. Dreht man sich im 3D 360 mal um jeweils 1° und geht da mit einer naiven Vorstellung von Gleitkomma ran, dann dreht man sich nicht exakt 1 mal im Kreis :-)
Die Pingeligkeit der Kaufleute in Bezug auf Rundungsfehler hat einen sehr guten Grund: die Bilanzierungsregeln. Eine Bilanz muß immer ausgeglichen sein, sonst stimmt irgend was nicht. Das hat zur Folge, daß schon mal die ganze Mannschaft eine Woche lang nach 3 verschollenen Pfennigen suchen muß. Wenn nun noch der Computer eigene Fehler dazu dichtet, dann wird es schier aussichtslos, derlei Unstimmigkeiten zu beheben.
@ Klaus Huber (devil4711) In deinem Beitrag verhält sich die Anzahl der Ausrufezeichen proportional zum Unsinn deiner Ausagen.
Trotzdem erkläre mir mal einer wieso man nicht einfach eine 64Bit Fixkommazahl in Binär nimmt, da kann ed dann doch gar nicht zu rundungsfehlern kommen oder irre ich mich da? Gruß Tom
Hi Bei binärem Fixkomma hat die erste Kommastelle einen Wert von 0,5. Dann folgt 0,25 0,125 0,0625 usw. Du siehst das man damit keine exakten Cent-Beträge wie etwa 0,01€ (sondern bei .8 Fixkomma nur 0,0099945068359375€) darstellen kann. Es kommt zu Fehlern selbst bei reinen Additionen. Und da sind die Banker eigen. Das wollen sie nicht haben. Das ist aber noch lange kein Grund ein Datum auch in BCD darzustellen. Matthias
Matthias Weißer schrieb:
> Das ist aber noch lange kein Grund ein Datum auch in BCD darzustellen.
So lange sich alle an die jeweilige Konvention halten, gibt es kein
wirklich gutes Argument für die eine, oder die andere Darstellung.
In solchen Nischen pflegt sich dann die Tradition zu halten.
Hi aber doch nicht mehr in einer neu zu entwickelndem Chipkartensoftware die der Authentifizierung dient. Irgendwann muss man auch mal mit alten Traditionen brechen. Aber noch ist ja nicht mal geklärt ob das wirklich der Fehler war. Matthias
Matthias Weißer schrieb: > aber doch nicht mehr in einer neu zu entwickelndem Chipkartensoftware > die der Authentifizierung dient. So lange sie mit alten Systemen kooperieren muß und nicht der gesamte Entwicklerstab neu aus dem Boden gestampft wird, sind neuentwickelte Systeme keine Welt für sich, die auf nichts bisheriges Rücksicht nehmen müssen. > Irgendwann muss man auch mal mit alten Traditionen brechen. Was glaubst du, wieviel uralter, seit Jahrzehnten nicht mehr geänderter Code ganz tief unten in den Betriebsystemen vor sich hin werkelt... So lange der seine Sache tut, gibt es keinen Grund, dort durch Neuimplementierung neue Fehler einzubauen.
Welche Möglichkeit siehst du noch, wenn es mit dem aktuellen Jahreswechsel einen Fehler in der Datumsprüfung gibt? Ich würde darauf Wetten, ganz konkret würde ich behaupten es war nicht spezifiert welche Notation benutzt werden soll und der französische Kartenlieferant hat vergessen es nachzufragen und die südostasiatische Kartenschmiede hat so geliefert wie sie ihrem Stammkunden immer beliefert. Alternativ hat jemand vergessen die Specs genau zu lesen.
Es war sehr wohl spezifiziert - anders sind solche Systeme, die von vielen Herstellen bedient werden - gar nicht machbar. Meine These: Da kam irgend so ein Jungspund daher, der nach dem Motto: "weg, jetzt komm ich" sich einen Dreck um die Specs gekümmert hat und überhaupt nicht auf die Idee kam, daß man für sowas eine Nicht-Binär-Darstellung nehmen könnte. Richtig schlimm ist allerdings, daß diverse Prüf- und Zertifizierungsstellen das nicht gemerkt haben. Banana-Software nennt man das. Die Ware reift beim Kunden.
Klaus Huber schrieb: > Ich habe noch nie gehört, das bei einem Jahreswechel, bei der Lufthansa > die Triebwerke ausgehen!!!!! http://www.welt.de/reise/article4682316/Rechnerausfall-loest-Chaos-bei-der-Lufthansa-aus.html und http://www.heise.de/newsticker/meldung/Lufthansa-Check-in-laeuft-nach-Computer-Ausfall-wieder-105719.html Man beachte die unterschiedlichen Daten.
Auch andere haben ein Jahr-2010-Problem :-) http://www.zdnet.de/news/wirtschaft_sicherheit_security_problem_mit_datumsstempel_behindert_symantec_updates_story-39001024-41525259-1.htm Reinhard
Auf meine Maschinen kommt auch ohne Datumsproblem keine Symantec-Software mehr...
Ganz ehrlich. Das in den Banken die Cobol-BCD Freaks rumlungern, weiß man ja. Von daher habe ich ein gewisses Verständnis, wenn neuere Programmierer, die nie gelernt haben wie BCD funktioniert, da einen Fehler machen. Dass aber ein Softwareschmiede von einem 'Jahr 2010-Problem' betroffen ist, kann ich einfach nicht verstehen. Was bitte ist an einem long long, der die Sekunden seit was weiß ich zählt, so speziell, dass er beim Jahreswechsel 2010 ein Problem macht? Oder an einem int, der die Jahreszahl enthält? Kein Programmierer seit 1980 tut sich freiwillig BCD an, wenn er nicht mit vorgehaltener Waffe dazu gezwungen wird.
Karl heinz Buchegger schrieb: > Kein Programmierer seit 1980 tut sich freiwillig BCD > an, wenn er nicht mit vorgehaltener Waffe dazu gezwungen wird. Das stimmt so nicht - aber das hatten wir weiter oben schonmal...
Uhu Uhuhu schrieb: > Karl heinz Buchegger schrieb: >> Kein Programmierer seit 1980 tut sich freiwillig BCD >> an, wenn er nicht mit vorgehaltener Waffe dazu gezwungen wird. > > Das stimmt so nicht - aber das hatten wir weiter oben schonmal... OK. Ich präzisiere: Kein Programmierer seit 1980 tut sich freiwillig BCD im Bereich von Datumsberechnungen an, wenn er nicht mit vorgehaltener Waffe dazu gezwungen wird oder direkt an einen RTC-IC ran muss, der nichts anderes liefert und keine Bibliotheksfunktion vorhanden ist, die die BCD-Kacke erst mal in ein 'vernünftiges' Format umwandelt. Wie Symatec es schafft, eine Datumsprüfung bei einem Update dermassen zu vergeigen, dass das Update nicht mehr akzeptiert wird, entzieht sich meinem Vorstellungsvermögen.
Karl heinz Buchegger schrieb: > Wie Symatec es schafft, eine Datumsprüfung bei einem Update dermassen zu > vergeigen, dass das Update nicht mehr akzeptiert wird, entzieht sich > meinem Vorstellungsvermögen. Ach, da fiele mir schon was ein: Von der Jahreszahl (numerisch) jeweils die Jahrhunderte wegschmeißen, dann beide in String wandeln (dabei verschwindet die führende Null von '09'), dann einen Vergleich der beiden Strings und schon ist '10' < '9' :-). Reinhard
Sowas ist wirklich schnell passiert, vorallem in heutigen Zeiten, wo "Time-To-Market" das Wichtigste ist und ausser dem einen Entwickler von diesem Modul kein anderer mehr darüberschaut.
Ich weiß nicht, ob "drüberschauen" da die Methode der Wahl ist. Für mich deuten solche Fehler einfach nur auf nicht vorhandene Qualitätssicherung am Endprodukt.
Reinhard R. schrieb: > Karl heinz Buchegger schrieb: >> Wie Symatec es schafft, eine Datumsprüfung bei einem Update dermassen zu >> vergeigen, dass das Update nicht mehr akzeptiert wird, entzieht sich >> meinem Vorstellungsvermögen. > > Ach, da fiele mir schon was ein: > > Von der Jahreszahl (numerisch) jeweils die Jahrhunderte wegschmeißen, > dann beide in String wandeln (dabei verschwindet die führende Null von > '09'), dann einen Vergleich der beiden Strings und schon ist '10' < '9' > :-). LOL. Da fällt mir der unweigerlich das KISS Prinzip ein :-)
Johnny B. schrieb:
> Sowas ist wirklich schnell passiert,
Da geb ich dir grundsätzlich recht.
Aber Datumsfunktionen?
Sowas sollte doch eigentlich in jeder ernstzunehmenden Basis-Library,
die zweifellos in jeder Softwarebude vorhanden ist, als Standardelement
vorhanden sein.
Ich schreibe CAD Programme. Und ja, die Basis-Lib die ich benutzen kann,
hat eine Datumsklasse. Und die Lib ist mitlerweile >15 Jahre alt.
Karl heinz Buchegger schrieb: > Sowas sollte doch eigentlich in jeder ernstzunehmenden Basis-Library, > die zweifellos in jeder Softwarebude vorhanden ist, als Standardelement > vorhanden sein. Vermutlich war aber genau das die Ursach für das Problem. Im Bankbereich muß man z.T. mit steinalten Vorgaben leben - da helfen moderne Standardbibliotheken nicht unbedingt weiter.
Karl heinz Buchegger schrieb: > Sowas sollte doch eigentlich in jeder ernstzunehmenden Basis-Library, > die zweifellos in jeder Softwarebude vorhanden ist, als Standardelement > vorhanden sein. Das ist ja noch schlimmer, denn wer kontrolliert schon die mitgelieferten libraries...
unit tests, die normalerweise für eine solche Basisfunktionalität angemessen wären
Entschuldigt meine "einfache gestrickte" frage... Wenn doch bekannt ist das gebrochene Darstellung ungenau ist, warum stellt man die Cents nicht als volle zahl dar ? Nach dem Motto : int32_t meine_euro; int8_t meine_cent; Die Darstellung ist dann genau, nur dran rumrechnen muss ich "per Hand".
Thomas W. schrieb: > Entschuldigt meine "einfache gestrickte" frage... > > Wenn doch bekannt ist das gebrochene Darstellung ungenau ist, > warum stellt man die Cents nicht als volle zahl dar ? Macht man doch! Nur Vollkoffer benutzen für monetäre Werte einen 'gebrochene Darstellung' (Schöner Asudruck, aber ich weiß was du damit meinst). > > Nach dem Motto : > > int32_t meine_euro; > int8_t meine_cent; Aber nicht so. Wenn schon, dann rechnet man der Einfachheit halber alles einfach in Cent oder Zehntelcent (damit man bei Prozentrechnung und Summation noch ein bischen 'Reserve' hat). 238 Euro und 20 Cent sind intern dann einfach eine uint32_t Variable mit dem Inhalt 23820 > Die Darstellung ist dann genau, > nur dran rumrechnen muss ich "per Hand". Auch nicht wirklich. Gerade bei monetären Werten kommen meistens nur Additionen vor. Und da wirkt sich die Kommaverschiebung nicht aus. Aufpassen muss man nur ein wenig bei Multiplikationen und Divisionen. Und was anderes als die Grundrechenarten kommt bei Geld nicht wirklich vor.
...also ein wenig wie die Unix Zeit. Aber bei Faktoren aus den Natürlichen Zahlen sollte es doch auch mit der Multiplikation keine Probleme geben. Bei der Division wird es dann schon blöd... Da kommem doch jetzt so Stichworte wie Ring und Körper ?!?? Wäre mal interessant zu wissen auf welches Konto halbe und viertel Cent gebucht werden :) Danke für die Erklärung. Offtopic im Offtopic : In einer Ausstellung wurde mal eine Binäruhr erklärt. Die Dame hat also auch erklären müssen wie man von Zehnersystem nach Binär und zurückrechnet. Auf die Frage wie man die Nachkommastellen darstellt musste sie passen ;) (daher die "gebrochene Darstellung" Gebrochene Zahlen -> Bruch -> 1/Z2,)
Karl heinz Buchegger schrieb: > Wenn schon, dann rechnet man der Einfachheit halber alles einfach in > Cent oder Zehntelcent (damit man bei Prozentrechnung und Summation noch > ein bischen 'Reserve' hat). Vorsicht! Das führt unweigerlich irgendwann zu Fehlern. Die kann man am besten dadurch umgehen, daß man in diesem Beispiel Cent speichert und alle Operationen, deren Ergebnis gebrochene Cent ergeben kann, mit höherer Genauigkeit berechnet und dann sofort auf Cent rundet. Das Problem ist, daß man den zwei ausgewiesenen Nachkommastellen nicht ansieht, was danach kommt. Wenn man also "mit Gewalt", also durch Rundung, dafür sorgt, daß die erste unsichtbare Stelle immer Null ist, dann können sich keine Fehler aufschaukeln, die plötzlich und unerwartet auf der 2. Nachkommastelle einen Effekt haben.
Das ist grausam ! So ein "kleines" Problem kann einen so beschäftigen. Aber mal ehrlich... Im Prinzip dürfte eine Bank doch hauptsächlich von : - Gutschriften aus dem nichts. (Schuldgeld) - Umbuchungen von anderen Konten - Zinsberechnung leben. Addition und Subtraktion sind für Rundungsfehler unkritisch. Nur die lieben Zinsen brauchen gebrochenes, da * und / direkt oder indirekt vorkommen... In der einfachsten Betrachtung sollte ein direktes Runden doch reichen. aber was ist mit dem ZinsesZins ? Nach N Jahren macht die Bank doch dann im schlimmsten fall n-1 Cent verlust/gewinn !? Oder fängt man dort wieder mal an "beliebig" (mathematisch) genau zu rechnen ???
Thomas W. schrieb: > Das ist grausam ! > So ein "kleines" Problem kann einen so beschäftigen. Tja, es ist grausam, in einer Bilanz mit einem Volumen von mehreren Millionen EUR zwei fehlende Cent suchen zu müssen... Deswegen muß die Arithmetik in kaufmännischen Programmen absolut stabil sein.
Uhu Uhuhu schrieb: > Vorsicht! Das führt unweigerlich irgendwann zu Fehlern. > > Die kann man am besten dadurch umgehen, daß man in diesem Beispiel Cent > speichert und alle Operationen, deren Ergebnis gebrochene Cent ergeben > kann, mit höherer Genauigkeit berechnet und dann sofort auf Cent rundet. Klar. Aber auch dafür muss es ein Regelwerk geben (das ich mangels Erfahrung mit Bankprogrammen nicht kenne) Die Legende berichtet, dass es mal einen cleveren Programmierer gab, der anstelle von kaufmännisch richtigem runden (oder was auch immer notwendig gewesen wäre) immer abgerundet hat und sich die Differenz auf sein Konto überwiesen hat. Nach dem Motto 'Auch Kleinvieh macht Mist' hat sich da in nicht allzulanger Zeit ein hübsches Sümmchen angesammelt.
Thomas W. schrieb: > Aber mal ehrlich... > Im Prinzip dürfte eine Bank doch hauptsächlich von : > > - Gutschriften aus dem nichts. (Schuldgeld) > - Umbuchungen von anderen Konten > - Zinsberechnung leben. Meine Theorie ist, dass Banken davon leben, dass Geld das ich heute auf den Weg bringe, erst in frühestens 3 Tagen auf dem Empfängerkonto landet. In den Tagen dazwischen 'borgen' sich die Banken das Geld um damit für die eigene Tasche zu 'arbeiten'. Was bei einer Überweisung heutzutage 3 oder 4 Tage dauert, konnte mir bisher noch keiner einleuchtend erklären.
Karl heinz Buchegger schrieb: > Aber auch dafür muss es ein Regelwerk geben (das ich mangels Erfahrung > mit Bankprogrammen nicht kenne) Es reicht, ein kaufmännisches Projet von Anfang bis Ende durchgezogen zu haben - dann hat man die Regeln so verinnerlicht, daß künftig nichts mehr schief geht ;-) Eigentlich kann man sich das mit dem gesunden Menschenverstand überlegen. Die Hürde für den, der mathematisch zu denken gelernt hat, liegt darin, daß man immer "möglichst genau" rechnen will, was einen dann daran hindert immer kleine Fehler zu machen, um große im Keim zu ersticken.
1. Hmmm, ein paar Stunden könnte ich mir noch vorstellen (technisch). 2. Ein paar Tage hat wohl eher was mit den "Gruppenüberweisungen" zwischen verschiedenen Banken zu tun. zu 1. So eine Überweisung läuft ja nach einer art Handshake ab. Es geht darum nur zu belasten wenn das "Geld" (-welch ein blödsinn) auch tatsächlich Gutgeschrieben wurde. Da kommt bestimmt jede Bestätigung in die Que... zu 2. zu 1 stimmt so nicht ganz. Um wirklich solche Überweisungen auszuführen muss von Bank A nach B auch mal tatsächlich "Geld", also scheine, Offizielles Zahlungsmittel ausgetauscht werden. Da wird dann gerne mal gesammelt, in der Hoffnung das viele Transaktionen in der Summe 0 ergeben. --- Kunde1 Bank A -> Bank B 100 € Kunde2 Bank A -> Bank B 200 € Kunde 3 Bank B -> Bank A 50 € Kunde 4 Nank B -> Bank A 75 € Kunde 5 Nank B -> Bank A 75 € Kunde 6 Nank B -> Bank A 100 € Ergibt in der Summe 0, es muss kein Zahlungsmittel transferiert werden. --- Buchungen aus dem Bündel brauchen nur Bankintern gebucht zu werden. Das kostet nix, stellt keine Sicherheitsrisiko dar (Jedenfalls nicht so wie beim Geldtransport). Kostet allerdings Zeit, da Buchungen gegeneinander gesammelt werden müssen.
Thomas W. schrieb: > Da wird dann gerne mal gesammelt, in der Hoffnung das viele > Transaktionen in der Summe 0 ergeben. Ist schon klar. Aber das ist ja nicht mein Problem. Auf meinem Konto wird der Betrag am Montag abgebucht um dann am Freitag auf dem Empfängerkonto gutgeschrieben zu werden. Und das in Zeiten, in denen ein 100-seitiges Buch in Sekundenbruchteil einmal um die Welt reisen kann :-) Ich verlange ja gar nicht, dass die Banken die Überweisung noch in der selben Sekunde tätigen. Wenn die Verbuchung mitten in der Nacht passiert, ist das schon ok. Aber das das Geld tagelang im Niemandsland hängt, finde ich in der heutigen Zeit inakzeptabel. Die Post schafft es ja auch in einer Nacht Millionen von Briefe und Pakete über Sammelstellen zu sammeln und in die Empfängerbreiche zu verteilen. Und da muss tatsächlich Materie bewegt werden.
...naja, bei der Bank bekommst du auch nicht genau den Schein zurück den Du eingezahlt hast. Banken sind komische Konstrukte. ...und wir wurden sehr lange in die jetzige Form hinein erzogen. Wenn ich in ein paar Monaten mal am Bankschalter stehen sollte frage ich mal nach ;)
>...naja, bei der Bank bekommst du auch nicht genau den Schein zurück den >Du eingezahlt hast. Doch, doch! Das Geld wird entgegen landläufiger Meinung in Schuhkartons aufbewahrt. Wie man sich in einer Bank korrekt verhält, veranschaulicht folgender Link: http://www.nonstop-nonsens.de/in-der-bank/ MfG Paul
Karl heinz Buchegger schrieb: > Ich verlange ja gar nicht, dass die Banken die Überweisung noch in der > selben Sekunde tätigen. Wenn die Verbuchung mitten in der Nacht > passiert, ist das schon ok. Daß Überweisungen ihre Zeit brauchen, hat einen guten Grund: Die Mindestlaufzeit beeinflußt im Zeitalter des bargeldlosen Zahlungsverkehrs die verfügbare Geldmenge und die ist ein Steuerinstrument für die Zentralbank. Nebenbei verschaffen sich die Banken auf diesem Weg natürlich auch nocht Liquidität.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.