Zeitrechnungen
« | 24 Feb 2019 | »Da meinte doch tatsächlich mal ein Java-Programmierer, ich solle keinen Code nutzen, der auf den Calendar - Klassen basiert und SimpleDateFormat einsetzt, denn diese sind nicht Thread-sicher.
Ich kann das ja immer noch nicht glauben, dass Java in seinem Aufbau so defekt ist, dass es Kalender-Rechnungen in globalen Variablen vermurxt und dann Fehler oder Abstürze produziert, wenn unterschiedliche Instanzen in Threads benutzt werden.
… doch offenbar melden mehrere Seiten solche Probleme.
Da mir einige C-Compiler (Stichwort: Windows CE) ebenso keine Zeitfunktionen anboten, hatte ich mir vor langem mal die Zeit genommen, die Zeit selbst zu berechnen.
… so schwer ist das ja nicht!
Wir starten brav im Jahr 1601 und können so schrittweise Datumsangaben in Sekunden, Millisekunden oder Mikrosekunden bis zum heutigen Datum hochrechnen.
Wichtig sind die Schaltjahr Regeln:
- Grundsätzlich ist jedes 4. (bzw. durch 4 teilbare) Jahr ein Schaltjahr, womit der Februar 29 statt 28 Tage hat.
- Jedes 100ste Jahr ist aber kein Schaltjahr!
- Doch jedes 400ste Jahr ist dann doch wieder ein Schaltjahr
Oder wie der C-Programmierer sagen würde:
Es reichen also schon einfachste Zählschleifen, um von Tag 0 am 1.1.1601, die bis zum gewünschten Tag hoch zu zählen und jeweils die Sekunden eines Tages (60 x 60 x 24 == 86400) aufzuaddieren.
Und wenn man Datumsangaben in Ganzzahlen übersetzen kann und umgekehrt, sind so “komplexe” Rechnungen wie die Differenz zwischen zwei Zeitpunkten ein Klacks.
Natürlich kann man das optimieren und Fixpunkte in Tabellen einbauen.
Den einzigen, den ich gerne nutze, ist die Unix-Geburtsstunde, am
1. 1. 1970
.
Doch sobald man weiß, dass dieser Zeitpunkt 11644473600
Sekunden vom
1. 1. 1601
entfernt ist, kann man auch schön zwischen Unix- und 1601-Zeit
umrechnen.
Also warum (zur Hölle) braucht Java für so eine Trivialität thread-unsicheren Code?
Daher habe ich mir die 100 Zeilen C Code zur Zeitumrechnung in eine Java Klasse
kopiert und arbeite nun aus purer Trotzigkeit damit.
Das soll doch wohl ein Scherz sein, dass erst neue Zeitklassen in Java 8 dieses
Problem im Jahr 2014 zu lösen versuchen und sämtlicher alter Java-Code “buggy”
wird, wenn man ein Datum als lesbaren Text ausgeben will!
Fazit: Hände weg von (einigen) Java-Klassen
Ich will jetzt ja nicht behaupten, dass alles an Java schlecht sei, aber solche Konzeptfehler dürfen in einer modernen Sprache nicht auftreten. Selbst C und C++ haben es im Jahr 2000 geschafft viele historische Funktionen Thread-safe zu gestalten ohne die Kompatibilität zu brechen.
Und dass das in Java 20 Jahre lang nicht möglich war halte ich für grob fahrlässig.