Der am natürlichsten wirkende Name “Date” ist bereits seit Java 1.0 durch die Klasse java.util.Date besetzt. Damit in Java-Programmen keine Namenskonflikte entstehen, die nur durch umständliche Zusatzangaben von Paket-Qualifizierern aufgelöst werden können, besteht die Notwendigkeit, wenigstens für die elementarsten und häufig verwendeten Klassen einer JDK-Erweiterung oder externen Bibliothek Namen zu wählen, die noch nicht vergeben sind.
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.