Die Studienarbeit "Optimierung und Erweiterung einer Klassenbibliothek zur Verarbeitung von Zeit- und Datumswerten" von Johannes Fasolt deckt am Beispiel Eiffel ein breites Specktrum an Fragen der Modellierung ab.
Calendar c = GregorianCalendar.getInstance();
c.setLenient(false);
c.clear();
c.set(2004, 11, 31);
System.out.println(c.getTime().toString()); "=> Fri Dec 31 00:00:00 CET 2004"
Monate fangen bei 0 an, Tage bei 1.
Mit Speicherplatz wird nicht gegeizt: GregorianCalendar hat 3 eigene Instanzvariablen und erbt dazu noch 13 von Calendar. Drei der geerbten Variablen sind Arrays, die je 17 Slots vorhalten. Date sieht auf den ersten Blick vergleichsweise schlank aus - nur zwei Instanzvariablen. Die eine ist allerdings ein Calendar, den Date mit der zweiten Variable synchronisiert.
Sowohl Date als auch Calendar sind Klassen, die Zeiten speichern! Das macht Datums-Vergleiche nicht eben leichter.
Ein Calendar erlaubt standardmäßig auch obstruse Daten, etwa den 30. Februar. Einer bereits vorhandene Calendar-Instanz kann man das mit setLenient(false) abgewöhnen. Es gab aber auch schon Bugs, die nur bei solchen, scharf prüfenden Calendars auftraten.
Die Schnittstelle ist trotz der fetten Klassen sehr dünn geraten. Für Vergleiche und Rechnungen sind kaum Services vorhanden. Und die vorhandenen lassen zu wünschen übrig. Die Calendar-Methoden before und after nehmen z. B. als Argument beliebige Objekte entgegen, liefern für Date aber nicht das erwartete Ergebnis.