nicht angemeldet
(ZUR INFO) angeblicher Y2K Bug in Perl ist keiner
Hallo Forumsleser,
weil es mich nervt, daß hier soviele Leute ihre Programmierfehler mit einem
angeblichen Bug in Perl entschuldigen, poste ich euch mal Auszüge aus
der Doku zu Perl. (perlfunc)
"localtime EXPR
Converts a time as returned by the time function to a 9-element array with the
time analyzed for the local time zone. Typically used as follows:
# 0 1 2 3 4 5 6 7 8
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
[..] Also, $year is the number of years since 1900, that is, $year is 123 in year 2023,
and notsimply the last two digits of the year. If you assume it is, then you create
Y2K-compliant programs--and you wouldn't want to do that, would you?"
Beachtet besonders den den letzten Satz (-:
CYa und ein schönes, gesundes und erfolgreiches Jahr 2000 (das letzte diese Jahrtausends)
GONZO
-
Converts a time as returned by the time function to a 9-element array with the
time analyzed for the local time zone. Typically used as follows:# 0 1 2 3 4 5 6 7 8
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);[..] Also, $year is the number of years since 1900, that is, $year is 123 in year 2023,
and notsimply the last two digits of the year."Absolute Zustimmung.
Denn jeder, der ein solches Datum in Perl weiterverarbeiten will, muß ja auch lernen, daß die Monate ($mon) im Intervall [0..11] geliefert werden und nicht etwa im Intervall [1..12]. Also muß man den Monat um 1 erhöhen - wenn man das vergißt, ist es auch kein bug von Perl, sondern einer des Programmierers.
-
Hallo Forumsleser,
"localtime EXPR
Converts a time as returned by the time function to a 9-element array with the
time analyzed for the local time zone. Typically used as follows:
[..] Also, $year is the number of years since 1900, that is, $year is 123 in year 2023,
and notsimply the last two digits of the year. If you assume it is, then you create
Y2K-compliant programs--and you wouldn't want to do that, would you?"naja, mein lieber Gonzo,
das ist schon ein wenig schräg gedacht und lebensfremd....
wenn man eine Systemvariable $year nennt, dann sollte das ein wenig lebensnaher sein und wenn man der den Inhalt 'Jahre seit 1900' gibt, dann sollte sie vielleicht $yearssince heißen oder so...in diese Falle ist ja auch Matt Wright mit seinem Gästebuch getappt und ich muß nun überall, wo ich das im Einsatz habe, einbauen:
ist $year größer als 99, dann subtrahiere....
weißt du, Erklärungen sind manchmal furchtbar logisch und der Erklärende hat recht, aber der Ansatz sollte etwas lebensnaher sein...
mit den Monaten von '0 bis 11' hat man ja als Alltags- und Feiertags-Programmierer mehr zu tun als mit einem 'Jahr größer 99'
dies mal zur Ehrenrettung der Leute, die dieses Verhalten als Fehler ansahen. Der Bug liegt nicht in PERL, der Bug liegt im Denkansatz dessen (sein Name ist mir grad entfallen), der das so angesetzt hat...
und noch was Ketzerisches: heißt PERL nicht was mit PRACTICAL.....? Praktisch ist das jedenfalls nicht...
Gruß
Connie-
Hi Connie
ist $year größer als 99, dann subtrahiere....
Dein Ansatz ist schon ganz nett, aber der Entwickler hat sich sicherlich folgendes dabei gedacht: 1900+$year. Dann hat man das aktuelle Jahr ohne irgendwelche Probleme. Damit kann man leicht das Jahr 2000 Problem umgehen. Somit ist diese Funktion so eigentlich gar nicht schlecht. Ich zumindest hab von anfang an so gearbeitet und keinerleih probleme mit Y2K.
mit den Monaten von '0 bis 11' hat man ja als Alltags- und Feiertags-Programmierer mehr zu tun als mit einem 'Jahr größer 99'
Über die Monate wundere ich mich immer noch. Ob dabei jemand nachgedacht hat bezweifle ich, aber man muß wohl damit leben.
Cu
Uwe-
... der Entwickler hat sich sicherlich folgendes dabei gedacht: 1900+$year. Dann hat man das aktuelle Jahr ohne irgendwelche Probleme. Damit kann man leicht das Jahr 2000 Problem umgehen. Somit ist diese Funktion so eigentlich gar nicht schlecht. Ich zumindest hab von anfang an so gearbeitet und keinerleih probleme mit Y2K.
Jedenfalls bis zum Jahr 2027. Danach könnte das eine Byte, welches bei der Zerlegung des Datumswertes möglicherweise intern verwendet wird (als "signed char"), überlaufen.
(Falls "unsigned char", dann kracht es Anfang 2156. ;-)mit den Monaten von '0 bis 11' hat man ja als Alltags- und Feiertags-Programmierer mehr zu tun als mit einem 'Jahr größer 99'
Über die Monate wundere ich mich immer noch. Ob dabei jemand nachgedacht hat bezweifle ich, aber man muß wohl damit leben.In C, Perl und anderen "Hackersprachen" ;-) ist es üblich, einen Array so zu definieren, wie intern auch der Code generiert wird, nämlich beginnend mit dem Element, das den Indexwert [0] aufweist. (erstes Element = Startadresse des Arrays plus offset von Elementbreite mal Null.)
Monatswerte von 0 bis 11 sind also geradezu ideal, einen "char [12]" in C zu adressieren, welcher Komponenten von [0] bis [11] (nicht [12]!) hat.
In Perl sind arrays dynamisch lang, aber man würde bei 1-12 immerhin das Element 0 verschenken ...-
Jedenfalls bis zum Jahr 2027. Danach könnte das eine Byte, welches bei der Zerlegung des Datumswertes möglicherweise intern verwendet wird (als "signed char"), überlaufen.
(Falls "unsigned char", dann kracht es Anfang 2156. ;-)Ach was interessiert mich das Jahr 2027 :-)
Naja momentan leben meine Scripte eh nur höchsten 2 Monate, dann gibts neue.In C, Perl und anderen "Hackersprachen" ;-) ist es üblich, einen Array so zu definieren, wie intern auch der Code generiert wird, nämlich beginnend mit dem Element, das den Indexwert [0] aufweist. (erstes Element = Startadresse des Arrays plus offset von Elementbreite mal Null.)
Monatswerte von 0 bis 11 sind also geradezu ideal, einen "char [12]" in C zu adressieren, welcher Komponenten von [0] bis [11] (nicht [12]!) hat.
In Perl sind arrays dynamisch lang, aber man würde bei 1-12 immerhin das Element 0 verschenken ...Ok die Erklärung ist gut. Das versteh sogar ich :-).
Wir wollen ja schließlich nix verschenken.
-
-
Hallo Uwe,
Dein Ansatz ist schon ganz nett, aber der Entwickler hat sich sicherlich folgendes dabei gedacht: 1900+$year. Dann hat man das aktuelle Jahr ohne irgendwelche Probleme. Damit kann man leicht das Jahr 2000 Problem umgehen. Somit ist diese Funktion so eigentlich gar nicht schlecht.
im Gästebuch-Script steht nur:
19$year
nix mit Addition...
zu kurz gedacht, na ja, ich muß halt ändern...
Gruß
Connie
-
-