Zeit für Java » Allgemein

Endet der Maya-Kalender? Nein, in Time4J wird er weiterleben!

Meno Hochschild — Thu, 20 Dec 2012 10:06:55 +0000

Pünktlich zum von Esoterikern postulierten Weltuntergangstag am 21. Dezember 2012 endet die von den meisten Wissenschaftlern und Archäologen angewandte sogenannte Lange Zählung des Maya-Kalenders (englisch: long count). Ja, eventuell sehen das manche Esoteriker das sogar als “Beweis” für ihre Weltuntergangsphantasie an. Wie auch immer, die Maya haben nach neueren archäologischen Funden wohl schon darüber hinausgezählt. Interessant hierzu auch das Interview mit dem deutschen Archäologen und Maya-Forscher Nikolai Grube. Also keine Angst vor dem Weltuntergang.

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.

Hat ein ISO-8601-Datum eine (gregorianische) Ära?

Meno Hochschild — Fri, 09 Nov 2012 12:33:50 +0000

Streng genommen lautet die Antwort kurz und bündig: NEIN!

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.

Über Schalttage des gregorianischen Kalenders

Meno Hochschild — Fri, 09 Nov 2012 11:53:34 +0000

Hier ein paar interessante Links:

Wikipedia

Warum ist die gregorianische Schalttagsregel die beste?

Der zweite interessante Link beleuchtet auch die mathematischen Probleme beim Definieren einer geeigneten Schalttagsregelung sehr gut. Die Regel wird zumindest bis in 3200 Jahren richtig sein. Danach müßte eine neue Regel her, aber das Problem ist jetzt nicht aktuell.

Datums- und Zeitbibliotheken in Java – eine Übersicht

Meno Hochschild — Mon, 10 Sep 2012 00:10:58 +0000

Zuletzt aktualisiert am 27.09.2012!

Will ich alle jemals existierenden Ansätze und fertige Bibliotheken auflisten, werde ich sicherlich nicht fertig. Die tatsächliche Anzahl ist auch nicht ermittelbar, weil viele Bibliotheken gar nicht öffentlich verfügbar sind. So gibt es in meiner Firma intern eine eigene Datumsklasse und auch eine eigene Uhrzeitklasse, die jeweils als Zustand Jahr, Monat, Tag und Stunde, Minute, Sekunde in Integer-Variablen halten und die Zeitrechnung an das JDK (java.util.GregorianCalendar) delegieren.

Bibliotheken, die lediglich die JDK-Kalenderklassen ummanteln und so einige unschöne Details verstecken und nach außen verbessern, gibt es in Unmengen. Auf diese Art und Weise kann z.B. die vielfach kritisierte Zählung des JDK von Monaten ab 0 (Januar) statt 1 (in der Umhüllung) leicht geändert werden. Eine unsortierte Mini-Auswahl von Open-Source-Bibliotheken dieses Typs sind zum Beispiel:

com.google.gdata.data.DateTime (Google Data APIs Client Library (1.41.1))
jOOCal von Lukas Eder
CalendarDate von Mark McLaren
Time and Money Code Library (inaktiv)
…

Ich möchte daher das Thema etwas anders formulieren: Wieviele eigenständige Bibliotheken gibt es, die alle wesentlichen Aspekte einer Zeitbibliothek selbst behandeln, ohne an das JDK zu delegieren und daher auch stand-alone verwendet werden können? Die folgende Übersicht behandelt genau diese. Es sind überraschend wenige, nämlich (nach meinem Kenntnisstand) nur 6, das JDK eingeschlossen! Wer nach dem Kriterium der Eigenständigkeit noch mehr solche Bibliotheken kennt, möge sie mir gerne mitteilen.

JDK – java.util.Calendar, sun.util.calendar-Paket etc.
JodaTime von Brian O’Neill und Stephen Colebourne
ICU-Projekt von IBM
JSR 310 (Threeten) von Stephen Colebourne, Michael N. Santos und Roger Riggs
BigDate von Roedy Green (Quellcode hier)
DATE4J von John O’Hanley

Zu den Bibliotheken BigDate und DATE4J ist allerdings anzumerken, daß sie nicht ganz eigenständig sind, da ihnen eine eigene Zeitzonenimplementierung fehlt und sie hierzu einfach nur die JDK-Klasse java.util.TimeZone verwenden (und das auch nur als Methodenparameter). Durch Weglassen von Merkmalen wird deren API natürlich leicht sehr schlank. Und das JDK selbst bietet zwar nur relativ wenige öffentliche Klassen an, hat aber im Hintergrund noch viele weitere Klassen und Pakete, ist also deutlich gewichtiger als auf den ersten Augenschein hin.

Merkmale/Eigenschaften	JDK	Joda	ICU	Threeten	BigDate	DATE4J
Anzahl öffentlicher Klassen (mit spi-Paketen)¹⁾	14	143	61	~75	1	3
Zugriff auf kalendarische Felder als Integer	☑	☑	☑	☑ ²⁾	☑	☑ ³⁾
Zugriff auf kalendarische Felder als Objekt (z.B. Monat-Enum)	☐	☐ ⁴⁾	☐	☑	☐	☐
Feldbereichsabfrage auf kalendarischen Feldern (Minimum/Maximum)	☑	☑	☑	☑	☐	☐
>>immutable<< Klassen (Thread-Sicherheit)	☐	☑	☐	☑	☐	☑
Abfrage der aktuellen Zeit über System.currentTimeMillis() oder now()/today()-Methoden	☑	☑	☑	☑	☑	☑
Abfrage der aktuellen Zeit über Uhrenabstraktion (injizierbare Clock-Klasse)	☐	☐	☐	☑	☐	☐
Genauigkeit in Sekunden	Milli	Milli	Milli	Nano	Tag ⁵⁾	Nano
Separate Typen für Datum und Uhrzeit (je Genauigkeitsgrad ein Typ)	☐	☑	☐	☑	☐ ⁵	☐
Variable Genauigkeit innerhalb eines Zeitpunkttyps	☐	☐	☐	☐	☐	☑
Erzeugung von Datum oder Zeit über Konstruktoren	☑	☑	☑	☐	☑	☑
Erzeugung von Datum oder Zeit über statische Fabrimethoden (ClassName.of(year, month, day) u.ä.)	☐	☐	☐	☑	☐	☑
Eigene Zeitzonenimplementierung	☑	☑	☑	☑	☐	☐
Quelle der Zeitzonendaten des JDK pre 8 ({java.home}/lib/zi)	☑	☐	☑	☐	☐	☐
Eigene Quelle der Zeitzonendaten (TZ-DB)	☐	☑	☑	☑	☐	☐
Historische Zeitzoneninformationen per UTC-Zeitabfrage	☑	☑	☑	☑	☐	☐
Historische Zeitzoneninformationen per nextTransition()	☐	☑ ⁶⁾	☐	☑ ⁶⁾	☐	☐
Historische Zeitzoneninformationen per Listing/Iterator	☐	☐	☐	☑ ⁶⁾	☐	☐
Erkennung von Zeitzonennamen (z.B. MESZ, PST)	☑	☐	☑	☐	☐	☐
Erkennung von Windows-Zeitzonen-IDs	☐	☐	☐	☐	☐	☐
Vordefinierte Konstanten für Standard-Zeitzonen-IDs (z.B. Europe/Paris)	☐	☐	☐	☐	☐	☐
Konfliktstrategie für Zeitzonenlücken/Überlappungen	☐	☑ ⁷⁾	☐	☑	☐	☐
Abstrakte Jahr/Monat/Tag-Basisklasse	☑	☑	☑	☑ ⁸⁾	☐	☐
Generisches API mit gemeinsamer Basisimplementierung für Chronologien ohne Jahr/Monat/Tag-Struktur	☐	☐	☐	☐ ⁹⁾	☐	☐
Unterstützung des UTC-Standards (Schaltsekunden)	☐	☐	☐	☐ ¹⁰⁾	☐	☐
Addition einer Dauer (add/plus/minus)	☑	☑	☑	☑	☑ ¹¹⁾	☑
Rolloperation (wie Addition, aber ohne Effekt auf größere Zeitfelder)	☑	☐	☑	☐	☐	☐
Typsicherheit in der Addition/Subtraktion	☐	☑ ¹²⁾	☐	☐ ¹²⁾	☐	☐
Konfliktstrategie für Monatsaddition ¹⁴⁾	☐	☐	☐	☐ ¹⁵⁾	☐	☑
Dauerberechnung zwischen zwei Zeitpunkten wie in MS-DotNet (t1.subtract(t2))	☐	☐	☐	☐	☐	☑ ¹⁶⁾
Dauerberechnung zwischen zwei Zeitpunkten ausgehend von der Zeiteinheit (units.between(t1, t2))	☐	☑	☐	☑	☐	☐
Dauer mit mehreren Zeitfeldern erzeugen (z.B. P3M1D)	☑ ¹⁷⁾	☑	☐	☑	☐	☐
Addition einer Dauer mit mehreren Zeitfeldern zu einem Zeitpunkt	☑ ¹⁷⁾	☑	☐	☑	☐	☐
XML-konforme Darstellung einer negativen Dauer (z.B. -P2D)	☑	☐	☐	☐	☐	☐
Intervalle mit je zwei Zeitpunkten (Start/Ende)	☐	☑	☐	☐	☐	☐
Format-API (eigene konfigurierbare Formatklassen mit CLDR-Unterstützung)	☑	☑	☑	☑	☐	☐
Zeitformat mit AttributedCharacterIterator ¹⁸⁾	☑	☐	☑ ¹⁹⁾	☐	☐	☐
Lokalisierte Wocheninformationen (erster Tag der Woche etc.)	☑	☐	☑	☑	☐	☐
Anzahl der vorinstallierten Kalendersysteme inklusive ISO (I18N)	3	6	10	6 ²⁰⁾	1	1
Tagesnummerierungsverfahren (Stichwort: Modified Julian Date)	☐	☐	☑	☑	☑	☑
Anpassung von kalendarischen Feldern über set/with-Methoden	☑	☑	☑	☑	☑	☐
Anpassung von kalendarischen Feldern über Adjuster-Verfahren (z.B. letzter Tag dieses Monats, erster Tag der nächsten Woche etc.)	☐	☐	☐	☑	☐	☐

¹⁾ In den gegebenen Zahlen sind auch spi- und Formatpakete wie java.text.* berücksichtigt. Während eine kleine Zahl für eine leichtere Erlernbarkeit spricht, zeigt sie in der Regel aber auch einen Mangel an Merkmalen und Eigenschaften an. Dieses Kriterium eignet sich somit nicht als Aussage zur Qualität einer Bibliothek.
²⁾ Als long-Primitive
³⁾ Feldwert als java.lang.Integer-Objekt
⁴⁾ Ersatzweise gibt es generische Property-Klassen.
⁵⁾ Reine Datumsklasse
⁶⁾ Komplexer uneinheitlicher Zugriff, Aufruf mehrerer Methoden für eine vollständige Historie notwendig
⁷⁾ Nur für Überlappungen (Wechsel von Sommerzeit zur Winterzeit, wenn eine lokale Zeitangabe zweimal existiert)
⁸⁾ Das grundlegende Design der Klasse ChronoDate, wie java.util.Calendar auf Jahr/Monat/Tag-Kalender eingeschränkt, ist wenige Monate vor dem vorgesehenen Projektende (Anfang 2013) unter den Projektleitern selbst noch stark umstritten.
⁹⁾ Es gibt zwar ein AdjustableDateTime-Interface, das aber erstens zuwenig bietet und zweitens keine abstrakte Skelettimplementierung hat.
¹⁰⁾ In einem separat hinzulinkbaren Erweiterungsmodul gibt es eine sogenannte UTC-SLS-Implementierung, die UT1-Zeiten zu TAI konvertieren hilft. Eine echte Unterstützung von UTC selbst inklusive Anzeige/Formatierung und Zeitrechnung gibt es leider nicht.
¹¹⁾ Nur Addition von Tagen, nicht Monaten oder Jahren
¹² Änderungen sind über Methoden wie plusMonths(), plusSeconds() etc. typsicher, aber die generische Variante plus(3, MONTHS) in Threeten ist es leider nicht, da sie z.B. auch auf eine reine Uhrzeit angewandt werden kann. Der Compiler läßt es durchgehen, zur Laufzeit fliegt dann eine Ausnahme… Joda wirft im Kontrast auch zur Laufzeit keine Ausnahme, ignoriert aber die unpassenden Argumente schweigend – eine fragwürdige Strategie.
¹⁴⁾ Was ist zum Beispiel [2012-01-30] + [1M]? => 29. Februar oder 1. März oder Abbruch?
¹⁵⁾ Dieses Merkmal war zwischenzeitlich implementiert, ist momentan aber wieder entfernt worden.
¹⁶⁾ Eingeschränkt auf Tage oder Sekunden über die Methoden numDaysFrom() und numSecondsFrom()
¹⁷⁾ Im JDK möglich über die wenig bekannte Klasse javax.xml.datatype.Duration!
¹⁸⁾ Notwendig zur Interoperabilität mit der javax.swing-Klasse JFormattedTextField, um dort ein Spinner-Verhalten zu realisieren. Merkwürdigerweise bietet Threeten im Gegensatz zum aktuellen JDK hier nichts, obwohl es als neue Zeitbibliothek für Java 8 vorgesehen ist.
¹⁹⁾ Hier nicht verifiziert, nur vermutet, da sich ICU strukturell eng an das JDK anlehnt.
²⁰ Stand von Anfang September 2012. Es sollen noch mindestens drei dazukommen, angeblich auch der (korrekt schwierig zu implementierende) hebräische Kalender.

Bewertung

Wie aus der Tabelle ersichtlich, ist keine Datums- und Zeitbibliothek perfekt. Auch ist überraschenderweise die vielgelobte Joda-Bibliothek keineswegs immer besser als das JDK. Allerdings können Joda und der designierte Joda-Nachfolger Threeten stark mit der Eigenschaft der Immutability punkten. Mit Sicherheit ist Threeten am ehesten ernst zu nehmen, befindet sich aber immer noch im alpha-Stadium. Weil niemand ernsthaft mit einem instabilen API arbeiten kann, lautet die Empfehlung zur Zeit immer noch Joda, obwohl es einige gravierende Schwächen aufweist, die so manchen trotzdem zum JDK haben greifen lassen. Da wären vor allem die fehlende lokalisierte Wochenunterstützung oder der Mangel an Unterstützung für die Swing-Komponente JFormattedTextField zu nennen. Vorsicht ist auch bei negativen Dauern angebracht (betrifft besonders Joda und leider auch Threeten). Und dann gibt es noch einige Features, auf die wohl auch die größten Threeten-Fans vergeblich warten werden, wie z.B. UTC-Schaltsekunden oder ein generisches Kalendersystem-API u.a. für Spieleentwickler. Es kommt nicht von ungefähr, daß die Anzahl der von Joda unterstützten Kalendersysteme relativ klein ist, obwohl Joda schon seit 2004 auf dem Markt ist. Ohne ein einigermaßen leicht zu handhabendes generisches API ist der Bau von neuen Kalendersystemen einfach zu schwer.

Wie umfangreich darf oder soll eine Datums- und Zeitbibliothek sein?

Der Umgang mit der Zeit und Kalendern ist komplex. Tatsächlich hat das Thema so viele mögliche Facetten, daß die obige Übersicht das nur unvollständig wiederzugeben vermag. Klar ist, daß die Beschränkung auf weniger als 10 Klassen (sogar nur eine im Fall von BigDate) notwendig mit dem Weglassen von vielen Features einhergehen muß. Insofern ist die Kritik mancher Java-Entwickler an Joda überzogen. Aber ein wahrer Kern steckt schon drin. Der abstrakte Überbau von Joda mit Namen wie AbstractReadableInstantFieldProperty überzeugt nicht wirklich. Threeten bringt hier Verbesserungen, aber zum Beispiel sein öffentliches Zeitzonen-API erscheint leider noch unnötig aufgeblasen. Wie wirbt ein gewisser oxbow_lakes für seine Scala-Bibliothek Saturn?

It is a bone-crushingly simple datetime library for those of us that have never needed:

non-Gregorian calendars
months that are not Jan-Dec, days of week that are not Mon-Sun etc.
to schedule a meeting on Klingon during the daylight saving era of Dhu’ruk-ha’a

Erstens ist oxbow_lakes etwas ungerecht, denn seine so simple Bibliothek ist in Wirklichkeit nur eine Hülle um das JDK herum (er verwendet zur Datumsrechnung die äußerst komplexe Klasse java.util.GregorianCalendar). Zweitens gibt es gerade im religiösen Umfeld viele, die andere Kalender brauchen (das sage ich selber als Atheist – eine Ironie), zum Beispiel hebräische Kalender, die auch etwas taugen (die ICU-Variante ist nicht ganz korrekt oder gar vollständig). Und selbst Klingon-Kalender sind für Spiele-Entwickler nicht abwegig. Zu guter Letzt: Wochentage sind selbstverständlich nicht immer von Montag bis Sonntag, in einem ziemlich wichtigen Land wie den USA fängt die Woche mit dem Sonntag an…

Was könnte man Menschen noch sagen, die für sie unwichtige Features gar nicht erst sehen wollen? Wichtig ist in Sachen Schlankheit vor allem, daß das Hauptpaket einer Bibliothek überschaubar bleibt und möglichst nicht mehr als 3 Zeit-Klassen (plus wenige Hilfsklassen) anbietet – eine für Datum, eine für die Uhrzeit und eine für die Kombination. Das JDK und ICU ziehen alles in einer Calendar-Klasse zusammen, was schon zu schlank ist. Andererseits ist Joda hier leider abschreckend mit >50 Klassen. Threeten ist deutlich besser mit 7 Zeit-Klassen, aber man fragt sich schon, was die Daseinsberechtigung einer Klasse wie OffsetDate ausmacht. Der XML-Hintergrund wäre sicherlich in einem xml-Unterpaket besser aufgehoben. Oder warum gibt es zwei Dauer-Implementierungen in Threeten, obwohl die eine Implementierung nur ein Spezialfall der anderen ist? Schlankheit bedeutet auch, daß die Klassen selbst nicht zuviele Methoden anbieten (ZonedDateTime in Threeten hat ca. 100 Methoden).

Fazit

Im Moment ist Joda zu empfehlen, in Zukunft Threeten (ab Java 8). Die alten JDK-Klassen werden dann leider immer noch nicht ausgedient haben, denn sie unterstützen einige Features, die auch Threeten nicht bietet. Es gibt also durchaus noch Raum für eine neue ultimative Datums- und Zeitbibliothek…

Zeitliche Genauigkeit eines SNTP-Java-Clients

Meno Hochschild — Sun, 29 Jul 2012 04:38:30 +0000

Zum Schaltsekundenereignis am 30. Juni 2012 habe ich aus Interesse einige Messungen mit einem in Java selbstprogrammierten SNTP-Client vorgenommen. Andere marktübliche Implementierungen stammen von Adam Buckley, Apache Commons oder von Google-Android. Die grundlegenden Programmiermuster solcher Implementierungen sind praktisch gleich – einfach aufgrund der Anforderungen des SNTP-Protokolls. Allerdings habe ich in meiner Lösung noch einige Debugging-Ausgaben und Logging-Fähigkeiten eingebaut. Auch habe ich zum Vergleich den üblichen Ausdruck System.currentTimeMillis() nur einmalig zur Initialisierung verwendet und bin dann immer vom Ausdruck System.nanoTime() ausgegangen, da hier aus dem PC die maximal verfügbare zeitliche Genauigkeit herausgeholt werden kann.Solche Zeitmessungen werten nicht nur die vom NTP-Server gemeldeten NTP-Zeitstempel (Festkommazahlen als Anzahl der Sekunden seit dem 1. Januar 1900) aus, sondern zwecks Schätzung der Laufzeitdifferenz im Netz auch die lokale Computer-Uhr. Entscheidende Messgröße ist die so erhaltene Differenz zwischen der lokalen Computer-Uhr und der über das SNTP-Protokoll ermittelten Netzzeit. Die Standardabweichung dieses Offsets liefert dann ein Maß zur Schätzung des mittleren Fehlers (hier des Mittelwerts) und ist letztlich das statistisch relevante Ergebnis dieses Artikels.

Die Hardware-Daten sahen bei mir wie folgt aus:

Lokaler PC mit Windows 7 => Intel(R) Core i7 CPU 2.93 GHz

NTP-Server => Physikalisch-Technische Bundesanstalt in Braunschweig (PTB), Stratum 1, NTP-Adresse “ptbtime1.ptb.de”

Internet-Connection => DSL 16000

Einige für die angegebene Hardware-Konstellation typische Messdaten mit Mikrosekundenanzeige:

Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=4.425048828125E-4, reference-identifier=PTB, reference-timestamp=2012-06-30T23:59:42,064662000Z, originate-timestamp=2012-06-30T23:59:50,809102000Z, receive-timestamp=2012-06-30T23:59:57,875550000Z, transmit-timestamp=2012-06-30T23:59:57,875559000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-06-30T23:59:57,898053000Z
Offset=7044423082
*************************************************
Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=4.57763671875E-4, reference-identifier=PTB, reference-timestamp=2012-06-30T23:59:42,064662000Z, originate-timestamp=2012-06-30T23:59:51,154119000Z, receive-timestamp=2012-06-30T23:59:58,240131000Z, transmit-timestamp=2012-06-30T23:59:58,240138000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-06-30T23:59:58,271604000Z
Offset=7054978015
*************************************************
Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=4.57763671875E-4, reference-identifier=PTB, reference-timestamp=2012-06-30T23:59:42,064662000Z, originate-timestamp=2012-06-30T23:59:51,517077000Z, receive-timestamp=2012-06-30T23:59:58,568375000Z, transmit-timestamp=2012-06-30T23:59:58,568382000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-06-30T23:59:58,583115000Z
Offset=7037023577
*************************************************
Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=4.57763671875E-4, reference-identifier=PTB, reference-timestamp=2012-06-30T23:59:42,064662000Z, originate-timestamp=2012-06-30T23:59:51,847118000Z, receive-timestamp=2012-06-30T23:59:58,893526000Z, transmit-timestamp=2012-06-30T23:59:58,893532000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-06-30T23:59:58,904998000Z
Offset=7035401682
*************************************************
Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=2.288818359375E-4, reference-identifier=PTB, reference-timestamp=2012-06-30T23:59:59,065810000Z, originate-timestamp=2012-06-30T23:59:52,170168000Z, receive-timestamp=2012-06-30T23:59:59,247781000Z, transmit-timestamp=2012-06-30T23:59:59,247788000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-06-30T23:59:59,275411000Z
Offset=7050516613
*************************************************
Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=2.288818359375E-4, reference-identifier=PTB, reference-timestamp=2012-06-30T23:59:59,065810000Z, originate-timestamp=2012-06-30T23:59:52,525063000Z, receive-timestamp=2012-06-30T23:59:59,566965000Z, transmit-timestamp=2012-06-30T23:59:59,566972000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-06-30T23:59:59,575551000Z
Offset=7033785196
*************************************************
Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=2.288818359375E-4, reference-identifier=PTB, reference-timestamp=2012-06-30T23:59:59,065810000Z, originate-timestamp=2012-06-30T23:59:52,842035000Z, receive-timestamp=2012-06-30T23:59:59,884087000Z, transmit-timestamp=2012-06-30T23:59:59,884093000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-06-30T23:59:59,892778000Z
Offset=7033833181
*************************************************
Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=2.44140625E-4, reference-identifier=PTB, reference-timestamp=2012-06-30T23:59:59,065810000Z, originate-timestamp=2012-06-30T23:59:53,159185000Z, receive-timestamp=2012-06-30T23:59:59,256841000Z, transmit-timestamp=2012-06-30T23:59:59,256847000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-06-30T23:59:60,294928000Z
Offset=6060019006

Besprechung der Messdaten:

Der letzte gemessene Offset lag um ca. eine volle Sekunde kleiner, weil er als Differenz zwischen lokaler (fortlaufender) Computer-Uhr und vom NTP-Server gemessener Atomuhrzeit die Tatsache reflektiert, daß der NTP-Server eine Schaltsekunde wiederholt, also zweimal den gleichen NTP-Zeitstempel liefert (im Rahmen einer Sekundenanzeige ohne Berücksichtigung der Nachkommastellen). Gleichzeitig läuft die Windows-Computer-Uhr trotz der Schaltsekunde einfach weiter. Daher wird auf den letzten zu kleinen Offset eine Sekunde aufaddiert, um dann die Fehlerrechnung anzuwenden.

Offset-Mittelwert der Stichprobe = 7,043747544 Sekunden

Standard-Abweichung der Einzelwerte = 0,010348006 Sekunden

Standard-Abweichung des Mittelwerts = 0,003658572 Sekunden

Ergebnis: Offset ~ 7,044 +/- 0,004 Sekunden

Die unter Windows-Betriebssystemen übliche Genauigkeit von ca. 10 Millisekunden konnte also auf besser als 4 Millisekunden gesteigert werden. Allerdings führt Windows gelegentlich selber automatische NTP-Synchronisationen mit meistens dem Windows-Time-Server unter “time.windows.com” aus, die zu größeren Sekundensprüngen in der lokalen PC-Zeit führen können. Bei den oben angegebenen Messdaten ist nach einem Blick in die Windows-Systemprotokolle sichergestellt, daß die Messdaten durch diese unabhängigen Synchronisationsvorgänge nicht verfälscht worden sind. Umgekehrt ist natürlich hieraus auch zu folgern, daß die NTP-Zeit wesentlich zuverlässiger als die PC-Uhr ist (der Offset im Beispiel von ca. 7 Sekunden ist erheblich bei lange nicht erfolgter Windows-Synchronisation).

Interessant ist auch, daß der PTB-Server zwar ständig einen leap-indicator (=1) sendet, aber dieser nicht geeignet ist, die aktuelle Schaltsekunde abzufragen. Vielmehr kündet er nur eine kommende UTC-Schaltsekunde an. Und dieses Flag wird auch nicht sofort mit Ende der eingefügten Schaltsekunde abgeschaltet. So wurde es auch mehr als 3 Minuten danach noch von der PTB gesendet:

Connecting NTP-Server, waiting for reply…
NTP-Server connected: de.menodata.time4j.utc.net.SntpMessage[version=4, mode=server, leap-indicator=1, stratum=1, poll-interval=0, precision=-22, root-delay=0.0, root-dispersion=3.662109375E-4, reference-identifier=PTB, reference-timestamp=2012-07-01T00:03:37,080589000Z, originate-timestamp=2012-07-01T00:03:40,327099000Z, receive-timestamp=2012-07-01T00:03:46,367308000Z, transmit-timestamp=2012-07-01T00:03:46,367315000Z]
NTP-Server signals positive leap second.
Last-Connection-Time=2012-07-01T00:03:46,376627000Z
Offset=6031366725

Erst ungefähr 8 Minuten später hat das leap-indicator-Flag den Normalwert 0. Zusammengefasst läßt sich sagen, daß das leap-indicator-Flag des NTP-Protokolls keine Möglichkeit bietet, eine bestimmte Sekunde als Schaltsekunde zu qualifizieren. Erst der Vergleich mit einer lokalen PC-Uhr in Kombination mit einem Offset-Sprung von ca. 1 Sekunde gestattet dies.

Ist Java schuld am Schaltsekunden-Crash zum 30. Juni 2012?

Meno Hochschild — Fri, 20 Jul 2012 16:11:41 +0000

Ja, meinte neulich ein Mozilla-Ingenieur, als mit der Einführung einer UTC-Schaltsekunde zur Synchronisation der langsamer werdenden erdrotationsgebundenen Zeit UT1 mit der Atomuhrzeit UTC etliche Linux-basierte Webserver abstürzten, und mit ihnen so manche populären Java-basierten Anwendungen darauf mit.

Sogar in der Threeten-Mailing-Liste des JSR-310-Teams, das eine neue Datums- und Zeitbibliothek für Java 8 entwickeln will, nimmt der bei Oracle für den JDBC-Bereich beschäftigte Douglas Surber die von Mozilla ausgestreuten Gerüchte für bare Münze und glaubt, daß die JSR-310-Referenzimplementierung Threeten derartige Probleme zuverlässig beseitigen würde. Als Begründung dient ihm, daß Threeten eine Minimalunterstützung für Schaltsekunden böte.

Meine Antwort in der Threeten-Mailing-Liste bezieht sich unter anderem auf eine fundiertere Analyse von John Stultz, die die Probleme tatsächlich auf Fehler im Linux-Kernel zurückführt. Java ist also völlig außen vor, und damit ist es im Hinblick auf die Server-Abstürze egal, was das JSR-310-Team als Schaltsekundenunterstützung rudimentär implementiert (oder auch gar nicht). Sowohl Java als erst recht auch Microsoft Windows sind bis jetzt gegenüber UTC-Schaltsekunden völlig ignorant und funktionieren trotzdem… Eine ganz andere Frage ist allerdings, ob Schaltsekunden nicht doch in irgendeiner Form unterstützt werden sollten, denn immerhin handelt es sich dabei um einen gesetzlichen Standard, der auch in der ISO-8601-Norm und im Internet-Protokoll RFC 3339 verankert ist.

Was lernen wir daraus? Nicht vorschnell irgendwelchen Gerüchten nachlaufen und daraus dann notwendig falsche Schlüsse ziehen. Wie auch in meinem letzten Kurzbeitrag zu populären Physikexperimenten angeklungen, rate ich zu mehr Un-Aufgeregtheit und Abwarten.

Zeit und Physik

Meno Hochschild — Thu, 19 Jul 2012 10:18:03 +0000

Dieser erste Blog-Beitrag ist eigentlich ein Verweis auf eine Serie von älteren Artikeln, die ich früher in einer Auseinandersetzung mit Kritikern der Relativitätstheorie von Albert Einstein geschrieben habe.

Während religiöse Spinner und Esoteriker keine ernsthaften und halbwegs rationalen Argumente gegen das Zeitverständnis der modernen Physik vorzubringen vermögen, lohnt es sich doch, auf die Kritik anderer Personen einzugehen, die in der Regel auf der Schulphysik basiert. Die Schulphysik setzt ihren Schwerpunkt auf die althergebrachte klassische Mechanik von Newton, Kepler und Galilei. Die Relativitätstheorie kommt allenfalls nur als Randthema in der Oberstufe vor. Hinzu kommt, daß die Alltagserfahrungen mit Raum und Zeit sehr gut zur Newton’schen Mechanik passen, aber die Relativitätstheorie dem sogenannten “gesunden Menschenverstand” – sprich den Alltagserfahrungen – zu widersprechen scheint.

Leider fühlen sich speziell im politischen linken Spektrum einige Kräfte bemüßigt, angeblich von der Perspektive des philosophischen Materialismus ausgehend nicht nur die Relativitätstheorie anzugreifen, sondern letztlich die gesamte Physikerzunft als Trottel darzustellen, die einem Scharlatan namens Einstein hinterherlaufen würden. Tatsächlich verwechseln diese Kräfte Materialismus (der sehr wohl die vielfältigen physikalischen Experimente zu würdigen hat, die zur modernen Physik führten) mit Sensualismus basierend auf ihren eigenen Alltagserfahrungen.

Die nachstehend zitierte Debatte ist dabei zuweilen recht hitzig abgelaufen. Es hat sich für mich auch nicht wirklich gelohnt, auf die zwischenzeitliche Raserei eines Egbert Scheunemann näher einzugehen. Raserei ist in der Regel ein starkes Indiz, daß dem Kontrahenten die Sachargumente ausgehen. Jedoch haben meine physikalischen Argumente Bestand, und ich glaube, die Leser können deshalb von der Lektüre sehr profitieren und die tiefen und fundamentalen Gedankengänge der Relativitätstheorie nachvollziehen, zumal ich fast überhaupt keinen Gebrauch von komplizierten mathematischen Formeln gemacht habe.

Sehen Sie selbst:

Marxismus und Relativitätstheorie