Java-Daten. Was für eine Saga. Früher rechneten wir fest mit der originalen Date-Klasse – einfache Timestamps, kein Drama. Dann platzte die Bombe mit Y2K-Panik und abgefahrenen Methoden, Oracles Vorgänger drückten uns Calendar als Retter in die Hand. Solider Einsatz, aber wuchtig. Jetzt rollt java.time.LocalDate als dritter Versuch an, gefeiert als unzerstörbare Lösung. Ist es aber nicht. Nicht vollständig.
Das ändert alles? Kaum. Es vertauscht nur einen Schmerz mit dem nächsten, zwingt Coder, jedes Mal 1 abzuziehen, um an Monatsnamen zu kommen. Wer profitiert? Du nicht, der um 2 Uhr nachts vor seinem Array-Index-Fehler starrt.
Ich decke Java ab, seit die Applet-Kriege tobten – 20 Jahre Sun, Oracle und jetzt Eclipse im Hickhack um die Treuhand. Daten bleiben Javas Achillesferse. Zeitzonen wandern wie Politiker, Schaltsekunden schleichen sich ein, jede API-Generation tut, als bezwinge sie das Chaos. LocalDate? Modern, unveränderlich, ISO-tauglich. Stark auf dem Papier. Aber schaut unter die Haube bei Month.getValue(), und Skepsis meldet sich.
Warum zählt Javas LocalDate Monate ab 1?
Hier liegt der Hund begraben. Nehmt LocalDate.now() – sagen wir, 2026-04-07 wie im Original-Beispiel. Ruft getMonth().getValue() auf, und zack: 4 für April. Logisch, oder? Passt zu ISO 8601, wo Januar 1 ist. Normalsterbliche nicken. Programmierer? Die sind auf Null-basiert dressiert, seit K&Rs C.
Euer bewährter Monatsnamen-Array – Januar bei 0, Februar bei 1 – passt plötzlich nicht. Indexiert mit getValue()? Ihr landet bei Mai statt April. Klassischer Off-by-One, die Geißel unseres Gewerbes.
Datum: 2026-04-07 Monat (val): Mai Monat (ord): April
Direkt aus dem Code-Demo der Vorlage. Am 7. April ausgeführt, druckt ordinal() (0-basiert, Index 3) April korrekt. getValue()? Erfordert Hack: MESES[fecha.getMonth().getValue() - 1]. Hässlich. Und jetzt in jedem neuen Codebase festgezurrt.
Ordinal() funktioniert weiter – Gott sei Dank –, hält an Januar=0 fest. Aber warum die Zwiespältigkeit? Wie ein Auto mit neuem Armaturenbrett, wo der Tacho bei 1 Kilometer startet. Passagiere finden’s intuitiv, Mechaniker flippen aus.
Moment – Ist 1-basiert nicht sogar besser?
Tabelle gefällig. Aus der Originalvorlage übernommen und angepasst:
| Methode | Basis | Beispiel | Konzeption |
|---|---|---|---|
| getValue() | 1 | Januar == 1 | Intuitiv |
| ordinal() | 0 | Januar == 0 | Gewohnheit |
Stichhaltig. Menschen zählen Januar als 1. Kinder lernen das so. Code? C’s localtime() packt tm_mon als 0. JavaScripts Date.getMonth()? Null-basiert, +1 für Anzeige. Perl, PHP – dasselbe. Sogar altes Calendar.get(Calendar.MONTH) ging von 0-11.
Zerbricht das euren alten Java-Code?
Kurz: Bei Migration zu java.time – ja, unterschwellig. Der uralte Monatsnamen-Hack, den alle kopiert haben? Tot. Seltsame spanische Monate (oder englische Pendants) tauchen in Logs auf. Ich prophezeie: Q2 2025 explodieren Stack-Overflow-Tiraden, wenn Teams für Jakarta EE upgraden.
Einzigartiger Twist, den noch keiner gebracht hat: Das erinnert an die Enum-ordinal()-Kriege in Java 5. Damals schrien alle, als Enums numerische Werte für Reflexions-Tricks opferten. Oracle hat nichts gelernt. Sie jagen ‘Reinheit’ – ISO-Konformität – auf Kosten pragmatischer Brüche. Wer kassiert? Red-Hat-Berater für Date-Audits. Oracles HotSpot JVM? Läuft egal.
Code-Fix? Banal, aber allgegenwärtig. Jedes Tutorial, jede Utils-Klasse – umschreiben. Im Enterprise-Java, wo Daten Lohnabrechnungen und Compliance fluten, sind das abrechenbare Stunden. Zynisch gesehen: Ideal. Hält die Java-Wirtschaft am Laufen.
Zurück in die Geschichte. C99 struct tm: tm_mon = 0-11, +1 zum Drucken. JavaScript ECMA-262: Explizit null. BASIC-Ausreißer mit 1-basiert? Cobol-Relikte, belächelt. Java hätte am De-facto-Standard festhalten können. Stattdessen ‘Innovation’ durch Intuition. Für Newbies. Auf Kosten der Veteranen.
Das große Ganze: Zeitzonen saugen immer noch
Nic
