www.mikrocontroller.net

Forum: Offtopic Das Jahr 2010 Problem


Autor: Dimitri Roschkowski (Firma: port29 GmbH) (port29) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

;-)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat da jemand ein BCD-Feld für die beiden letzten Stellen der Jahreszahl 
binär interpretiert?

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der vorteil von bcd hat sich mir auch noch nie erschlossen.
Immer diese Scheißumrechnung mit divisionen durch die binär schiefe 10

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ahh, danke für die Erläuterung.

Aber Speicher ist doch teuer ;-)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
9.9 Identify drive
...
| Word |                                                        |
...
| 53   | 15-1 Reserved                                          |
|      |    0 1=the fields reported in words 54-58 are valid    |
|      |      0=the fields reported in words 54-58 may be valid |

Was zum Geier[tm] soll man als Implementierer mit so einem Unfug
anfangen?  "may be valid"?  "may be standard"?  The "may be"
standard.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
>
> 9.9 Identify drive
> ...
> | Word |                                                        |
> ...
> | 53   | 15-1 Reserved                                          |
> |      |    0 1=the fields reported in words 54-58 are valid    |
> |      |      0=the fields reported in words 54-58 may be valid |
> 
>
> 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 ;)

Autor: Gerry E. (micky01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn man mal SCSI und ATA auf der Protokollebene vergleicht kann man 
auch leicht feststellen, wer von wem abgekupfert hat. :-)

Autor: Hannes H. (mui)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann sollte das Problem schon vor dem Jahr 2000 erkannt worden sein.

Ich bleibe dabei: das war Absicht! ;-)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo, lediglich du warst Absicht!

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Thilo, lediglich du warst Absicht!

Ja, und zwar in böswilliger Absicht Uhus zu ärgern. :)

Du musst es wissen ...

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wäre aber nicht das gleiche

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Hieß das nicht beim Z80 "H" (half-carry)?

Stimmt - möglicherweise hieß es beim 8080 so.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> für die gleiche Gneauigkeit brauchst du bei BCD mehr Speicher

Das Argument spielt heute keine Rolle mehr.

Autor: Hannes H. (mui)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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>

Autor: Hannes H. (mui)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dimitri Roschkowski (Firma: port29 GmbH) (port29) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumindest ist mir aufgefallen, dass immer mehr Onlineshops die 
Jahreszahl der Kreditkarte 4-Stellig abfragen.

Autor: Dimitri Roschkowski (Firma: port29 GmbH) (port29) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, aber ich kenne keinen einzigen Shop, der die Vierstellig abfragt. 
In der Regel wird eh in dem Format MMYY abgefragt.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erst gestern flybe.com & paypal, aber auch andere und es werden mehr.

Autor: Dimitri Roschkowski (Firma: port29 GmbH) (port29) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jeffrey Lebowski (the_dude)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-mues...

Autor: Gerry E. (micky01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Rundungsfehler hast Du bei ner Fixkomma Binärzahl doch auch nicht.

Gruß
Tom

Autor: Gerry E. (micky01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Die Rundungsfehler hast Du bei ner Fixkomma Binärzahl doch auch nicht.
>
> Gruß
> Tom

Ja, hast Recht.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dimitri Roschkowski (Firma: port29 GmbH) (port29) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerry E. (micky01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dimitri Roschkowski (Firma: port29 GmbH) (port29) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dimitri Roschkowski (Firma: port29 GmbH) (port29) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Paul Baumann (paul_baumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ändere nie ein laufendes System.
(Alte Elektrikerweisheit) ;-)

MfG Paul

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
#include <stdio.h>

int main (void)
{
  double j;
  
  for( j = 0.0; j < 5.0; j += 0.1 )
    if( j == 2.0 )
      printf( "Habs\n" );

  return 0;
}

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.

Autor: Dimitri Roschkowski (Firma: port29 GmbH) (port29) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Huber (devil4711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Manfred von Antenne (dipol)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Klaus Huber (devil4711)

In deinem Beitrag verhält sich die Anzahl der Ausrufezeichen 
proportional zum Unsinn deiner Ausagen.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Paul W. (dantor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Rechneraus...

und

http://www.heise.de/newsticker/meldung/Lufthansa-C...

Man beachte die unterschiedlichen Daten.

Autor: Reinhard R. (reirawb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch andere haben ein Jahr-2010-Problem :-)
http://www.zdnet.de/news/wirtschaft_sicherheit_sec...

Reinhard

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf meine Maschinen kommt auch ohne Datumsproblem keine 
Symantec-Software mehr...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard R. (reirawb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unit tests, die normalerweise für eine solche Basisfunktionalität 
angemessen wären

Autor: Thomas W. (wagneth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (wagneth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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,)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (wagneth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ???

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (wagneth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (wagneth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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 ;)

Autor: Paul Baumann (paul_baumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Yahoo-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.