Die Versionslinien 1.x und 2.x sind mittlerweile veraltet und als Experimentierphase zu werten, weil sich das Design der Version 1.0 aus guten Gründen doch inkompatibel ändern musste.

• Die Versionsline 1.x hatte keine saubere Trennung zwischen lokalen und globalen Typen.
• Die Versionslinie 2.x war in ihrem Kern für Android einfach zu groß.

Aber die Versionslinien 3.x für Java 6+7 (und in Zukunft Android) sowie die neue Versionsline 4.x für Java 8 sind jetzt ausgereift und stabil. Inkompatible Änderungen habe ich in Zukunft nicht mehr vor. Das ist nun in Stein gemeißelt.

Die neue Version v4.0, so kann man mit gutem Recht feststellen, hat nun endgültig die so vielgerühmte Joda-Time-Bibliothek und auch die in Java-8 eingebaute Zeitbibliothek (JSR-310) überholt, was die Anzahl und Qualität der unterstützten Features angeht. Lediglich einige Kalendersysteme fehlen im Vergleich.

Was fehlt noch? Gibt es ein Problem? Tja, Time4J ist noch so gut wie unbekannt, auch weil ich so gut wie nicht die Werbetrommel gerührt habe, sondern nur auf die Entwicklung fokussiert war. Und ein Marketing-Profi bin ich nicht, muß ich offenherzig bekennen. Trotzdem bekenne ich mich weiterhin zur Pflege und Weiterentwicklung dieser jetzt schon formidablen Bibliothek. Es gibt noch viel zu tun. Die Bibliothek ist bei weitem nicht fertig. Ich habe noch sehr viele Ideen. Allerdings werde ich jetzt die (extreme) Entwicklungsgeschwindigkeit verlangsamen, weil meine Gesundheit und meine Familie nicht weiter vernachlässigt werden dürfen.

Für alle Anwender, die NICHT Maven als build-Tool verwenden, gibt es den folgenden Link zum Download:

https://github.com/MenoData/Time4J/releases/tag/v1.1

Release v1.0

Und die nächsten Aufgaben warten schon: Intervalle und Formatierung von Zeitdauern (milestone M3).

http://github.com/MenoData/Time4J

Zweieinhalb Jahre harter Arbeit liegen da hinter mir, und meine Familie hat schon einige Male ganz schön geseufzt. Aber ich denke, das Ergebnis kann sich sehen lassen, auch wenn natürlich dieser Erstversion noch einige Features fehlen. Und nach der Arbeit ist bekanntlich vor der Arbeit. Die Entwicklung bleibt nicht stehen, sondern geht selbstverständlich weiter. Schwerpunkt des nächsten Release v0.2-alpha werden die Umstellung der Dokumentation auf Englisch, extra Tutorials und mehr Zeitzonen-Features sein.

An der Tatsache, daß ich leider nur relativ wenig Zeit in das Projekt investieren kann, wird sich wegen meiner privaten Situation so schnell nichts ändern. Darum werde ich auch demnächst wenig bis gar nichts bloggen, sondern lieber meine wenige vorhandene Zeit in Time4J stecken so gut es geht. Eine Ausnahme werde ich aber machen, wenn der “Public Draft Review” (PDR) des JSR 310 erscheint. Die neue Zeitbibliothek des JDK von Oracle und Stephen Colebourne steht kurz vor dem Abschluß. Dazu werde ich eine ausführliche Stellungnahme im Blog abgeben, fest versprochen.

<R extends Temporal> long between(R dateTime1, R dateTime2);

Zitat von S. Colebourne:

I’ve examined the generics on the temporal classes twice now. It isn’t possible to enhance their generics without making a terrible mess. Because Java doesn’t have the Self-type generic, or the notional of parameter self-type generic where the class is final, and because LocalDate extends ChronoLocalDate, it is more or less impossible to go further than we have.

Und das Fazit des JSR-Teams inklusive von R. Riggs von Oracle lautet dann, die Generics sang- und klanglos zu entfernen. Mehr oder weniger unmöglich. Wirklich?

Nehmen wir noch einmal die Klasse Temporal unter die Lupe. Wir finden da nicht-generische Methoden wie:

Sehr unbefriedigend daran ist natürlich, daß null Typsicherheit gegeben ist. Zu einem Temporal-Date könnte eine Implementierung in der plus()-Methode theoretisch eine Sekunde addieren und einen Zeitstempel als Kombination von Datum und Zeit zurückgeben. Es ist so wirklich beliebig. Der Compiler ist mit allem zufrieden. Nur in der Spezifikation der plus()-Methode steht dann, daß Implementierungen den gleichen Typ zurückgeben müssen. Sicherlich hat dieser offensichtliche Design-Mangel Stephen Colebourne dazu bewegt, noch mal einen Blick daraufzuwerfen – leider ohne Ergebnis. Und wenn doch, würde es auch nichts mehr nützen, weil zu einer konsequenten aber sehr zeit- und arbeitsintensiven Umstellung des JSR-Projekts auf Generics schon längst keine Zeit mehr vorhanden ist. Die Debatte, die Colebourne losgetreten hat, ist wenige Tage vor dem Java-8-Meilenstein M6!!!, also recht sinnfrei.

Ich habe mich im Gegensatz zum JSR-Team von Anfang an mit dem Problem der Generics in einer Datums- und Zeitbibliothek beschäftigt, nämlich in Vorstudien ab Oktober 2011. Und das Ergebnis meiner Überlegungen ist schon im Frühstadium in die Entwicklung von Time4J ab Herbst 2012 eingeflossen. So sieht das Ergebnis aus:

Ich habe eine abstrakte Klasse mit dem Namen TimePoint. Diese Klasse referenziert sich selbst über Generics. Konkrete Subklassen müssen final sein und die Generics auflösen, nämlich in einem ersten vereinfachten Schritt so:

abstract class TimePoint<T extends TimePoint<T>> {…}

final class IsoTime extends TimePoint<IsoTime> {}

final class IsoDate extends TimePoint<IsoDate> {}

Und dann betrachten wir erneut die oben erwähnte between()-Methode, was bei der Eingabe verschiedener Argumenttypen für T passiert (z.B. IsoDate und IsoTime):

<T extends TimePoint> long between(T start, T end); // Compiler sagt: OK

<T extends TimePoint<T>> long between(T start, T end); // Compiler verweigert

Entscheidend für die Compile-Time-Type-Safety ist also das “self-referencing-generics”-Feature. Freilich ist dieses Feature nicht neu. Es wird schon seit Java 5 in der bekannten Klasse java.lang.Enum angewandt. Und auch für Stephen Colebourne ist es nicht unbekannt, wurde er mehrfach in seinem eigenen Blog darauf hingewiesen, zuletzt 2012. Aber offenbar WILL er das Feature nicht einbauen und erklärt es für “terrible mess”, zu deutsch etwa: “furchtbar umständlich”.

Ich bin hingegen der Meinung, daß Generics hier das Problem der Typsicherheit zur Kompilierzeit entscheidend lösen können, während gleichzeitig konkrete Anwendungen, die die finalen Subklassen IsoDate und IsoTime nutzen, davon quasi nichts mitbekommen, weil die selbstreferenzierenden Typparameter auf dieser Ebene gar nicht mehr vorkommen. Es sind somit auch keine störenden Typparameter oder gar Wildcards im Anwendungscode notwendig. Also wirklich nur Vorteile auf der ganzen Linie.

Verschweigen will ich allerdings nicht, daß zwar Anwendungen ungemein von Java-Generics in dieser Form profitieren, aber der Framework-Bau auf dieser Basis hoch anspruchsvoll ist. So ist meine tatsächliche Lösung in Time4J noch etwas komplizierter. Zum Beispiel ist die obige Signatur der Klasse TimePoint wie folgt erweitert worden:

abstract class TimePoint<U, T extends TimePoint<U, T>> {…}

Hier steht der Typparameter U für das zugehörige System von Zeiteinheiten. Es hat sich nämlich gezeigt, daß es in einer gegebenen Chronologie ausgedrückt durch eine TimePoint-Klasse nicht sinnvoll ist, beliebige Zeiteinheiten zuzulassen. Ein Zeitpunkt ist inhärent über seine Koordinaten (als Zustandsattribute modelliert) auch mit einer Zeitachse verbunden, auf der der Zeitpunkt liegt. Die zulässigen Zeiteinheiten, die letztlich Längenabstände auf der Zeitachse messen, müssen zu den Koordinaten passen. Z.B. ist eine Zeitarithmetik basierend auf Sekunden in einer reinen Datumsklasse unsinnig. Also auch hier über den zweiten Typparameter U eine wichtige Maßnahme für mehr Typsicherheit. Die finalen Subklassen IsoDate und IsoTime lösen auch diesen U-Typparameter konkret auf.

Der Framework-Bau mit dann zwei Typparametern U und T ist natürlich nicht einfach und erfordert großen Aufwand. Tatsächlich ein Aufwand im Bereich des low-level-API, mit dem ich schon weit mehr als 1 Jahr beschäftigt (und jetzt praktisch fertig) bin. Wahrscheinlich hat das JSR-310-Team diesen Aufwand schon 2007 nicht leisten können und wollen. Jetzt ist es erst recht viel zu spät für den JSR, diesen Weg im Design einzuschlagen. Ich fürchte auch, sie haben noch nicht einmal wirklich den Weg gesehen. Schade!

Ist damit der alte Maya-Kalender beendet? Im historischen Sinne nach dem Kriterium des alltäglichen Gebrauchs ist er es schon längst. Aber ich habe beschlossen, ihn ein winziges Stück weit für historisch Interessierte weiterleben zu lassen. In meinem Projekt Time4J – eine neue Datums- und Zeitbibliothek geschrieben in der Programmiersprache Java – wird es auch eine MayanDate-Klasse geben. Kalendarische Grundlage wird der englischsprachige Eintrag zum Maya-Kalender in Wikipedia sein. Wie dort schön zu sehen ist, sind die kalendarischen Algorithmen des Kalenders erstaunlich einfach, deutlich einfacher jedenfalls als im modernen ISO-8601-Kalender. Um so mehr erstaunt es, daß z.B. eine so renommierte Bibliothek wie Joda Time so eine Komponente nicht hat. Nicht einmal eine externe Bibliothek mit dem Maya-Kalender basierend auf Joda Time scheint es da zu geben. Das einzige, was ich im Internet gefunden habe, ist ein kleines Applet zum Thema. Da bietet Perl mehr! Höchste Zeit, diesem Mangel von Java abzuhelfen.

Wann ist damit real zu rechnen? Insgeheim hatte ich gehofft, daß Time4J pünktlich zum Weltuntergangstag seine Geburt erleben sollte. Aber manchmal dauern Wunder ein wenig länger, gerade bei der Komplexität der anderen weit wichtigeren Kalendersysteme, die auch zu implementieren sind. Ich glaube eher an Spätsommer 2013. Also noch ein wenig Geduld bitte, verehrte Leser.

Die Frage steht also im Raum, wie ein alternativer Name eines neuen Datumstyps aussehen kann. Der JSR 310 (Threeten) hat sich schon vor langer Zeit auf den Namen “LocalDate” festgelegt. Das hat eine unglaublich lebhafte Debatte mit sage und schreibe schon 169 Beiträgen alleine in der ersten Hälfte des Dezember 2012 ausgelöst, in der viele Teilnehmer sich geradezu vehement gegen den vorgesehenen Namen “LocalDate” wehren. Meiner Meinung nach mit dem berechtigten Argument, daß der Name suggeriert, daß ein lokaler Zeitzonenbezug vorliegt. Tatsächlich liegt überhaupt kein Zeitzonenbezug vor. Aber Stephen Colebourne, der Projektleiter von Threeten/JSR 310 hat unmißverständlich klar gemacht, an seiner Namensgebung nicht rütteln zu wollen.

Interessant finde ich in dem Zusammenhang, daß offensichtlich viele zwar abstrakt den JSR 310 immer gut fanden, jedoch, wenn es konkret wird und die Einführung von Threeten in das JDK vor der Tür steht, erst dann sich etwas näher mit dem Thema und möglichen Schwächen beschäftigen. So mancher erschrickt dann beim Blick auf die Details, aber für größere Änderungen an Threeten ist es schon seit geraumer Zeit viel zu spät!

Wie wird sich mein Projekt Time4J hierzu verhalten? Nun, als externe Bibliothek ist Time4J grundsätzlich nicht in der Position, unabhängig von Threeten einen Namen zu wählen. Also kommt (beim derzeitigen Stand) “LocalDate” für Time4J nicht in Frage. Davon abgesehen halte ich den Namen wie auch die anderen Kritiker mit dem gleichen Argument für zumindest unglücklich gewählt, weil der Name doch Raum für Verwirrung läßt.

In der Debatte wie auch schon etliche Jahre früher (ich glaube 2009/2010), wurden u.a. auch die Namen “IsoDate” und “PlainDate” vorgeschlagen. Ich denke, das sind die beiden besten Alternativen zum bereits vergebenen Namen “Date”. Eventuell ist auch noch “StdDate” eine Wahl. Im Moment optiere ich für “IsoDate” aus folgenden Gründen: Erstens ist der Name immer noch relativ kurz. Zweitens erinnert das Präfix “Iso” an die strikte Konformität mit dem ISO-8601-Standard. Drittens sorgt es für eine gute Abgrenzung zu alternativen Datumstypen wie MayanDate, PersianDate, HebrewDate etc. Viertens läßt das “Iso”-Präfix keine Assoziationen zu Zeitzonen aufkommen.

Der christliche gregorianische Kalender und der daraus abgeleitete ISO-Kalender sind im Hinblick auf Äras und Jahreszahlen nicht gleich. Was sind die Folgen für Java-Datumsbibliotheken?

Im entsprechenden ISO-Dokument findet sich nirgends ein Hinweis auf eine Ära wie AD = Anno Domini (auf Deutsch: nach Christi Geburt). Im Gegenteil werden ein Jahr 0 und auch negative Jahre ausdrücklich zugelassen, unter der Maßgabe, daß sich die Partner im Datenaustausch darauf geeinigt haben, die Schalttagsregeln des gregorianischen Kalenders proleptisch, also auch rückwirkend vor der Einführung des Kalenders 1582 anzuwenden. Ein Jahr 0 oder gar negative Jahre gibt es im christlichen Kalender nicht. Stattdessen gibt es nur positive Jahreszahlen UND eine Ära-Angabe wie v.Chr. oder n.Chr. Das ISO-Jahr 0 entspricht dann 1 v.Chr., das ISO-Jahr -1 dem historischen Jahr 2 v.Chr. und so weiter. Soweit, so klar.

Hieraus könnte der Schluß gezogen werden, daß eine Java-Implementierung eines ISO-konformen Datums keine Ära-Angaben unterstützen sollte. Das würde dem nicht-religiösen weltlichen Charakter der ISO-Definition am besten entsprechen. Für den christlichen Kalender könnte dann ein separater Datumstyp mit Ära-Unterstützung implementiert werden. Leider sieht die Verwendungspraxis anders aus. Erstens gibt es diejenigen Menschen, die aus religiösen Motiven noch das Ära-Konzept verwenden möchten (ausdrücklicher Bezug auf den postulierten Zeitpunkt von Jesu Geburt). Zweitens und noch wichtiger läßt sich die Tatsache nicht leugnen, daß der christliche Kalender vor Einführung des ISO-Standards in der Praxis die Norm war und daher viele historische Zeitangaben herumschwirren, die mindestens beim Formatieren und Parsen eine Unterstützung des Ära-Konzepts brauchen.

Im Zusammenhang mit historischen Datumsangaben gibt es noch eine Besonderheit: Je nach Land wurde der gregorianische Kalender zu verschiedenen Zeitpunkten eingeführt, oft als Ablösung des julianischen Kalenders (mit durch 4 teilbaren Schaltjahren von Cäsar eingeführt). Zum jeweiligen Umstellungszeitpunkt wurde zwar die Wochentagsregelung beibehalten, aber es verschwanden mehrere Tage. In Italien folgte bekanntlich auf Donnerstag, den 4.Oktober 1582 (julianisch) der Freitag mit dem gregorianischen Datum 15. Oktober 1582. In England erfolgte die Umstellung 1752 (da sogar mit einem 11-Tage-Sprung). Und so weiter… Zuletzt erfolgte 1949 in China die Umstellung auf den gregorianischen Kalender. Es ist unschwer zu sehen, daß ein ISO-Datum wie “1582-10-09″ im historischen Kontext nicht als “9. Oktober 1582 n.Chr.” formatiert werden darf, sondern vielmehr als “30. September 1582 n.Chr.” formatiert werden muß. Mit anderen Worten: Sobald in der Darstellung eine Ära auftaucht, muß das historisch korrekte Datum verwendet werden, nicht das ISO-Datum, wenn es sich um ein Datum vor der Einführung des gregorianischen Kalenders handelt.

Wie löst Java das Dilemma zwischen der weltlichen ISO-Definition und dem tatsächlichen religiösen oder historischen Gebrauch?

Das JDK mit der Klasse GregorianCalendar definiert überhaupt keinen ISO-Typ. Somit ist das beschriebene Dilemma nicht vorhanden (aber zu einem hohen Preis). Diese Klasse ist ein Hybrid aus julianischem und gregorianischem Kalender und bietet über die Methode “public void setGregorianChange(Date date)” die Möglichkeit an, den Umstellungszeitpunkt individuell zu setzen. Allerdings gibt es keine Möglichkeit, das auch länderspezifisch zu tun. Ähnlich verhalten sich das Unicode-Konsortium und die IBM-Bibliothek ICU4J. In den Unicode-Ressourcen fehlt ein echter ISO-Bezug. Stattdessen wird so getan, als ob ISO auch eine gregorianische Ära kennen würde. Eine Differenzierung zwischen ISO und christlichem oder historischem Kalender fehlt. Entsprechend ist auf den ersten Blick nicht von vornherein klar, ob eine Datumsangabe julianisch oder per ISO-Norm gemeint ist. Sehr verwirrend für Anwender!

Joda-Time definiert anders als das JDK einen eigenen Typ namens GJChronology. Das ist schon viel besser, da hier im Verwendungskontext klar ist, was Datumsangaben bedeuten. Einen kleinen Wermutstropfen gibt es aber noch: Die Joda-Klasse ISOChronology kennt trotzdem eine Ära. Dies mag zwar auf den ersten Blick diejenigen freuen, die eine Ära in der Darstellung sehen möchten, aber das geschieht zum Preis von historisch evtl. falschen Datumsangaben. Gefährlich, auch wenn die Joda-Dokumentation diesen Mangel klar darstellt und von der Verwendung im historischen Kontext abrät. Auch ist eine länderspezifische Konfiguration des Umstellungszeitpunkts nicht möglich.

Was macht Threeten (JSR 310)? Noch gibt es kein HistoricDate. Aber ein solcher Datumstyp ist angedacht und wird nach den neuesten Meldungen (Issue-Tracker auf GitHub) wohl erst für Java 9 realisiert werden. Im Prinzip ist es das gleiche Verfahren wie in Joda… Und auch die LocalDate-Klasse von Threeten, die als ISO-Datum deklariert wird, kennt eine Ära (Nachteile siehe Joda).

Welchen Weg wird  mein ProjektTime4J einschlagen? Einen dritten Weg.

1. Es wird keinen separaten historischen Datumstyp geben (=> einfacheres API).

2. Die Klasse IsoDate wird an und für sich keine Ära kennen. Sie wird auch keinen gregorianischen Umstellungszeitpunkt verwalten, sondern nur von Jahr, Monat und Tag im proleptischen gregorianischen Kalender (ISO-Kontext) abhängig sein.

3. IsoDate wird eine lokale Erweiterung definieren, über die ein Anwender separat neben dem eigentlichen ISO-Datum ein historisches Datumsmodell abhängig vom Land erzeugen kann. Anschließend kann mit Hilfe des historischen Datumsmodells eine beliebige historisch korrekte Ausgabe des ISO-Datums erfolgen.

Dieses Verfahren bietet folgende Vorteile:

• Die meisten Verwender eines ISO-Datums brauchen sich nicht um Äras zu kümmern (und tun es auch nicht). Die IsoDate-Klasse hat einen klar weltlichen Charakter passend zum modernen Gebrauch.
• Christlich-religiös motivierte Menschen und Historiker werden trotzdem bedient, denn sobald sie in der Formatierung eines IsoDate-Objekts nach einer Ära fragen, erfolgt automatisch im Hintergrund die Erzeugung des passenden historischen Datumsmodells und die Umstellung auf eine historisch korrekte Ausgabe.
• Auch kann in der Formatierung für den gregorianischen Umstellungszeitpunkt eine Ländereinstellung berücksichtigt werden, die für die Sprachausgabe der Textelemente sowieso notwendig ist.
• Und zu guter Letzt kann die natürliche Ordnung von IsoDate rein zeitlich UND konsistent mit equals() bleiben, so daß einer Verwendung von IsoDate als Schlüssel in einer java.util.SortedMap oder in einem java.util.SortedSet nichts entgegensteht. Denn der gregorianische Umstellungszeitpunkt (englisch: cut-over) wird als Zustand nicht in IsoDate, sondern in einem separaten Objekt verwaltet. Die JDK-Klasse GregorianCalendar oder die Joda-GJChronology haben notwendig diesen Zustand intern und können deshalb entweder nicht mit einer java.util.TreeMap kooperieren oder definieren eine Sortierung, die nicht nur zeitlich ist!

Time4J beschreitet also gänzlich neue Pfade auch auf diesem Gebiet.