Mit diesen Worten hat Yoda in Starwars nicht nur eine der traurigsten Szenen aufgelockert, sondern auch gleich – unbeabsichtigt – ein Grundproblem der Javawelt adressiert. Die API für die Zeitverwaltung.
Wann wenn nicht jetzt?
Beim Stöbern in Quellcode bin ich letztens wiedermal über eine lustige Zeile gestoßen:
... System.currentTimeInMillis() //we can get the time in milliseconds after 1 Jan 1970 at 0:00:00am GMT ...
Auf den ersten Blick harmlos. Was soll da schon passieren? Ich will die Frage umformulieren: Was passiert danach? Mit dem Wert wird in der Regel angefangen zu arbeiten. D.h. Tage werden hinzugefügt, abgezogen um z.B. Startzeitpunkte zu ermitteln. Dabei wurde in dem Code, den ich gesehen habe in etwa folgendes gemacht:
final long now = System.currentTimeInMillis(); final long oneDay = 1000 * 60 * 60 * 24; final long tomorrow = now + oneDay; ...
Sieht immer noch alles harmlos aus? Dann weiter …
Ein Tag hat 24 Stunden
An einer anderen Stelle wurde ein Vergleich zweier Daten durchgeführt. Hier die anonymisierte Fassung:
final long oneDay = 1000 * 60 * 60 * 24;
final Calendar calendar = Calendar.getInstance();
calendar.set(2009, 9, 24, 10, 0);
final long summerTime = calendar.getTimeInMillis();
final Calendar comparisonCalendar = Calendar.getInstance();
comparisonCalendar.set(2009, 9, 26, 10, 0);
final long winterTime = comparisonCalendar.getTimeInMillis();
final long difference = winterTime - summerTime;
if (difference == 2 * oneDay) {
...
}
Immer noch harmlos? Der ein oder andere wird jetzt sagen: klar. Leider steckt der Teufel im Detail. Was meistens vernachlässigt wird ist die europäische (Un)Sitte zwischen Sommer- und Winterzeit zu wechseln oder auch ganz allgemein alle 4 Jahre mal einen Tag im Februar mehr einzuplanen. Hier muss sich dieser Ansatz leider geschlagen geben.
Ich muss mich an dieser Stelle entschuldigen, denn ich habe den Code bereits so abgeändert, dass das Problem der Sommer- und Winterzeit offensichtlich wird. Der Originalcode sieht natürlich etwas anders aus. Aber nun sollte definitiv ersichtlich werden, warum das nicht funktionieren kann. Hier wird mit festen Zeitintervallen (oneDay) gearbeitet. Leider hat der Tag zum Zeitwechsel nicht 24, sondern entweder 23 oder 25 Stunden.
Geht man mit Java-Hausmitteln an dieses Problem landet man dann aber auch schnell in Code-Schnippseln wie dem Folgenden:
... Calendar calendar = Calendar.getInstance(); Date now = calendar.getTime(); calendar.add(Calendar.HOUR_OF_DAY, 1); ...
oder die Alternative für den Vergleichscode:
...
Calendar calendar = Calendar.getInstance();
calendar.setTime(2009, 9, 24, 10, 0);
calendar.add(Calendar.HOUR_OF_DAY, 2);
Calendar comparisonCalendar = Calendar.getInstance();
comparisonCalendar.setTime(2009, 9, 26, 10, 0);
if (calendar.getTimeInMillis() == comparisonCalendar.getTimeInMillis()) {
...
Damit löst man zwar das Problem mit der Zeitumstellung, aber auf Dauer ist schön was anderes, denn ein weiterer Schwachpunkt der API, aus meiner Sicht, ist die schlechte Lesbarkeit. Denn wer sieht schon auf den ersten Blick, dass hier nicht der September, sondern der Oktober gemeint ist. Ja, man kann auch mit den Calendar-Konstanten arbeiten, aber auch das führt eher zu unnötig langen Codezeilen.
… einer, der der Macht das Gleichgewicht bringen wird …
Eine elegante Lösung hierfür bietet – nein nicht Skywalker, sondern – die Joda-Bibliothek. Diese erlaubt es das Millisecond-Massaker zu umgehen und die Schwächen der Standard-API zu minimieren. So sieht der Code von oben mit Joda etwa so aus:
... DateTime dt = new DateTime(); DateTime oneDayLater = dt.plusDays(1); DateTime oneDayEarlier = dt.minusDays(1); ...
Auch Vergleiche wirken wesentlich angenehmer:
final DateTime now = new DateTime();
final DateTime before = now.minusDays(100);
final Days days = Days.daysBetween(before, now);
if (days.getDays() == 2) {
...
“Schneller, leichter, verführerischer”
Auch wenn das nur ein erster Blick auf Joda war, zeigt sich hier schon die Eleganz und Mächtigkeit dieser Bibliothek. Wer sich nicht scheut ein wenig englisch zu lesen, sei für weitere Informationen auf das IBM-Tutorial Joda-Time und die Website http://joda-time.sourceforge.net selbst verwiesen.
Ansonsten, sehen wir uns in 900 Jahren um Mitternacht 
final LocalDate localDate = new LocalDate(); final DateTime then = localDate.toDateMidnight().toDateTime().plusYears(900);