Mich würde - allein schon aus beruflichen Gründen - wirklich mal interessieren, was die eigentliche Ursache des Problems ist. Ein Dezimalüberlauf (vulgo: "Einstellige Speicherung der Jahreszahl") ist vollkommen absurd - aber vielleicht gerade deswegen gar nicht so unwahrscheinlich. Eine hexadezimale Interpretation der zweistelligen Jahreszahl? Klingt wahrscheinlich.
Wenigstens ist es beruhigend, dass durch den Bug ein Sicherheitsmechanismus zu scharf greift; umgekehrt wäre es dann doch ein wenig unschöner als jetzt. ;-)
Eigentlich sind schon zweistellige Jahreszahlen Teufelszeug - aber da im Bankwesen ja gerne gespart wird ist die einstellige Jahreszahl gar nicht so unwahrscheinlich. Offenlegung von Details erwarte ich allerdings keine (das ist ja alles so geheim...), allenfalls auf wikileaks.
Das mit der hexadezimalen Interpretation wäre ja ein Superhit. Dann hätten sie zwar im Jahr 2000 tatsächlich etwas gemacht, aber eben schleißig.
Ich könnte mir aber durchaus vorstellen, dass irgendein Modul bereits hätte abgelöst werden sollen. Es hat sich verzögert und man hat darauf vergessen, dass es ja unbedingt bis Ende der Dekade durchzuführen gewesen wäre.
Originalton: "bis 2009 wird es reichen und dann gibt's eh was Neues." :)))
aber weils so schön herpasst:
wir hatten jahrelang(!) eine datumsumsetzungsroutine im einsatz, die gewisse oktober-datümer nicht richtig verarbeitete. wenn ich mich recht erinnere, wurden die tage, die sozusagen zwei nullen (wie 10-01, 10-02,..) haben, auf 10 tage später umgesetzt und kamen damit so nie vor ...
(und weil die oktobersumme aber dadurch überhaupt nicht auffällig war, fiel es so lang nicht auf ...)
irgendwie kommt mir 2010 auch so zweinullig vor;-)
Da ich quasi schon immer mit Datenbanken zu tun hatte (von den ganz frühen BASIC- Pascal- und Assemblerausflügen mal abgesehen) habe ich solchen Murks wie zweistellig gespeicherte Jahreszahlen erst wieder in den guten alten COBOL-Programmen gesehen, die aber dennoch ohne wirkliche Probleme den Sprung ins Jahr 2000 verkraftet haben - allerdings mußten wir damals die Hardware tauschen...
Wenigstens ist es beruhigend, dass durch den Bug ein Sicherheitsmechanismus zu scharf greift; umgekehrt wäre es dann doch ein wenig unschöner als jetzt. ;-)
Ich könnte mir aber durchaus vorstellen, dass irgendein Modul bereits hätte abgelöst werden sollen. Es hat sich verzögert und man hat darauf vergessen, dass es ja unbedingt bis Ende der Dekade durchzuführen gewesen wäre.
Originalton: "bis 2009 wird es reichen und dann gibt's eh was Neues." :)))
bisschen spät,
wir hatten jahrelang(!) eine datumsumsetzungsroutine im einsatz, die gewisse oktober-datümer nicht richtig verarbeitete. wenn ich mich recht erinnere, wurden die tage, die sozusagen zwei nullen (wie 10-01, 10-02,..) haben, auf 10 tage später umgesetzt und kamen damit so nie vor ...
(und weil die oktobersumme aber dadurch überhaupt nicht auffällig war, fiel es so lang nicht auf ...)
irgendwie kommt mir 2010 auch so zweinullig vor;-)
Da ich quasi schon immer mit Datenbanken zu tun hatte (von den ganz frühen BASIC- Pascal- und Assemblerausflügen mal abgesehen) habe ich solchen Murks wie zweistellig gespeicherte Jahreszahlen erst wieder in den guten alten COBOL-Programmen gesehen, die aber dennoch ohne wirkliche Probleme den Sprung ins Jahr 2000 verkraftet haben - allerdings mußten wir damals die Hardware tauschen...