nicht angemeldet
... 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 ...