Java tarihleri. Ne destan ama. Eskiden orijinal Date sınıfının sorunsuz çalışacağını düşünüyorduk — basit zaman damgaları, drama yok. Sonra Y2K korkusu ve acayip metodlarla patladı, Oracle’ın öncüleri Calendar’ı kurtarıcı diye sundu. Fena değil ama hantal. Şimdi java.time.LocalDate geldi, üçüncü girişim olarak kurşun geçirmez çözüm diye alkışlandı. Ama değil. Tam değil.
Her şeyi değiştiriyor mu? Hiç sanmam. Sadece bir baş ağrısını diğerine çeviriyor, ay adını her aldığında 1 çıkarmaya zorluyor. Kim kazanıyor burada? Sen değil, sabaha karşı 2’de dizi indeksi hatasıyla boğuşan.
Bak, applet savaşlarından beri Java’yı takip ediyorum — Sun, Oracle ve şimdi Eclipse’in sahipliği kavgalarını 20 yıldır izliyorum. Tarihler hep dilin topuk tendonuydu. Saat dilimleri politikacı gibi kayıyor, artık saniyeler sızıyor, her API yine kaosu yenecek diye hava atıyor. LocalDate? Modern, değişmez, ISO uyumlu. Kağıt üstünde harika. Ama Month.getMonth()’a bir bak, alaycılık devreye giriyor.
Java LocalDate Ay Sayımı Neden 1’den Başlıyor?
İşte mesele. LocalDate.now()’u al — diyelim 2026-04-07, orijinal şikayetteki gibi. getMonth().getValue() de, pat: Nisan için 4. Mantıklı, değil mi? ISO 8601’e uyuyor, Ocak 1. Kod bilmeyenler başını sallıyor. Ama programcılar? Biz K&R’ın C’sinden beri her şeyi sıfır tabanlıya alıştık.
Güvenilir ay adları dizin — 0’da Enero, 1’de Febrero — birden uyumsuz kalıyor. getValue() ile indeksle? Abril yerine Mayo’ya düşüyorsun. Klasik off-by-one, mesleğimizin vebası.
Fecha: 2026-04-07 Mes (val): Mayo Mes (ord): Abril
Bu doğrudan kaynak kod demosundan. 7 Nisan’da çalıştırınca ordinal() (0 tabanlı, 3. indeks) ile Abril doğru basıyor. Ama getValue()? MESES[fecha.getMonth().getValue() - 1] diye hack gerekiyor. Çirkin. Ve artık her yeni koda gömülü.
Ordinal() hâlâ çalışıyor — allah razı olsun — Ocak’ı 0’da tutuyor. Ama neden ikiye bölüyorlar? Araba kadranını yenileyip kilometresayacı 1 km’den başlatmak gibi. Yolcu için sezgisel, tamirci için sinir bozucu.
Peki 1 Tabanlı Olmak Daha mı İyi?
Tablo vakti. Orijinalden uyarladık:
| Yöntem | Temel | Örnek | Kavram |
|---|---|---|---|
| getValue() | 1 | Enero == 1 | Sezgisel |
| ordinal() | 0 | Enero == 0 | Alışkanlık |
Haklı nokta. İnsanlar Ocak’ı 1 diye sayar. Çocuklar öyle öğrenir. Ama kod? C’nin localtime() tm_mon’u 0 yapar. JavaScript Date.getMonth()? Sıfır tabanlı, gösterme için +1. Perl, PHP — aynı hikaye. Eski Calendar.get(Calendar.MONTH) bile 0-11’di.
Bu Eski Java Kodunu Bozar mı?
Kısa cevap: java.time’a geçiyorsan evet — sinsice. Yıllardır kopyala-yapıştır ay adı hilesi? Bitti. Loglarda garip İspanyol ay adları (veya İngilizce muadilleri) çıkınca debug yaparsın. Jakarta EE için yükseltirken Q2 2025’te Stack Overflow isyanları patlar diye tahmin ediyorum.
Kimse değinmemiş benzersiz açı: Bu Java 5’teki Enum ordinal() kavgalarını yankılıyor. O zaman enum’lar sayısal değerleri bırakıp reflection numaralarına dönünce çığlık koptu. Oracle ders almamış. ‘Saflık’ peşinde — ISO uyumu — pragmatik kırılmalara tercih ediyor. Kim kâr ediyor? Tarih denetimi için para alan Red Hat danışmanları. Oracle HotSpot JVM’si? Her türlü satıyor.
Kod düzeltmesi? Basit ama her yerde. Her tutorial, her utils sınıfı — yeniden yaz. Kurumsal Java’da maaş ve uyum uygulamalarına bulaşan tarihler için bu faturalı saatler demek. Alaycı tarafım diyor: Mükemmel. Java ekonomisini döndürüyor.
Tarihe sprint. C99 struct tm: tm_mon 0-11, basmak için +1. JavaScript ECMA-262: açık sıfır. BASIC gibi 1 tabanlı uçlar? Cobol kalıntıları, gülüp geçiyoruz. Java fiili standarda sadık kalabilirdi. Ama ‘yenilik’ sezgiyle geldi. Acemilere. Ustaların masrafına.
Büyük Resim: Saat Dilimleri Hâlâ Berbat
Rahat etme. LocalDate saati tamamen atlıyor — saat yok, ofset yok. Doğum günü için iyi. Ama ZonedDateTime’a bağla? Saat dilimi verileri gecikiyor, hükümetler DST’yi keyfine göre değiştiriyor. Java’nın tzdb’si IANA’dan çekiyor ama JAR şişmesi bekl
