Wenn ich nach Abschätzungen in Softwareprojekten gefragt werde, dann antworte ich immer „es dauert n Zeiteinheiten“.
Involviert das Projekt irgendwas mit € oder Kujambel oder anderen Währungen, ist die Antwort „n2 Zeiteinheiten“. Kommt zusätzlich i18n (Internationalisierung) drin vor, ist es“n3 Zeiteinheiten“, ist noch Datumsberechnung wichtig, ist es „n4„. Pro Element steigt der Exponent also um eins. Nehmt ihr euch dieser Fausregel an, werdet ihr erstaunlich weniger daneben liegen, als andere Schätzungen. Wirklich.
Ein Beispiel. Denkt man „wie schwer kann denn Datumsberechnug sein“, beginnt das Drama schon mit dem HelloWorld dieses Themas.
Denn Der folgende Test schlägt fehlt:
@Test
public void testSetMonth() throws DatatypeConfigurationException {
// gcal
GregorianCalendar gcal = new GregorianCalendar();
gcal.set(2015, Calendar.JULY, 19);
assertEquals(Calendar.JULY, gcal.get(Calendar.MONTH));
// xmlcal
XMLGregorianCalendar xmlcal =
DatatypeFactory.newInstance().newXMLGregorianCalendar(gcal);
assertEquals(Calendar.JULY, xmlcal.getMonth()); // KABOOM!
}
Ich setze den Monat mit set(...Calendar.JULY...)
und lese den Monat mit getMonth()
. Ist das etwa falsch? Ja? Nein? Ein Blick ins API ist unumgänglich. Aber welches?
Woran liegt das? Java Historie bei allem was mit Datum zu tun hat. Also der Date
-Klasse. Nee, ich meine der Calendar
-Klasse. Äh, ich meinte GregorianCalendar
…. ups, XMLGregorianCalendar
….
And so it begins. And never ends.
/rant
Der Artikel Datum in Java erschien zuerst auf icancode.de.