Zeitrechnungen

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:

gate_bool_t gate_time_is_leap_year(gate_uint16_t year)
{
  if(0 == (year % 400)) return true;
  if(0 == (year % 100)) return false;
  if(0 == (year % 4)) return true;
  return false;
}

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.