Das Land Samoa hat beschlossen, einen Tag auszulassen, den 30. Dezember 2011, den es auf Samoa nicht gibt. Diese Entscheidung wurde aus wirtschaftlichen Gründen getroffen. Ich frage mich, welche potenziellen Probleme wir bei der Softwareentwicklung für unsere IT-Systeme in Abhängigkeit von der Zeitzoneninformation bekommen können? Einen Tag zu überspringen, das klingt alles so einfach. Zunächst einmal war ich neugierig, ob es in der Vergangenheit ähnliche Situationen gegeben hat und welche Fallstricke es bei der Softwareentwicklung geben könnte. Eine kleine Untersuchung hat mir gezeigt, dass man mit Annahmen über regionale Zeitzonen vorsichtig sein muss. Schauen wir uns einmal an, wie eine Programmiersprache wie JAVA mit dieser Art von Situationen umgeht.
Um zu demonstrieren, welche Folgen diese detaillierten Zeitzonenänderungen haben und wie JAVA damit umgeht, habe ich das folgende Beispiel zusammengestellt (Apia ist die Hauptstadt von Samoa):
1. TimeZone timeZoneApia = TimeZone.getTimeZone("Pacific/Apia");
2. SimpleDateFormat sdf = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss");
3. sdf.setTimeZone(timeZoneApia);
4. Calendar calendar = new GregorianCalendar(timeZoneApia);
5. calendar.set(2011, 11, 29, 23, 59, 59);
6. System.out.println(sdf.format(calendar.getTime()));
Die Ausgabe von Zeile 6 ist offensichtlich:
29-12-2011 23:59:59
Fügen Sie nun die folgenden Zeilen hinzu:
7. calendar.add(Calendar.SECOND, 1);
8. System.out.println(sdf.format(calendar.getTime()));
Die Ausgabe von Zeile 8 hängt von der von Ihnen verwendeten JAVA 7-Version ab. Wenn Sie das ursprünglich veröffentlichte JAVA 7 oder JAVA 7 Update 1 verwenden, lautet die Ausgabe:
30-12-2011 00:00:00
Wenn Sie JAVA 7 Update 2 ausführen (oder wenn Sie eine frühere Version von JAVA 7 verwenden und die Zeitzonen-Konfiguration aktualisiert haben), lautet die Ausgabe:
31-12-2011 00:00:00
Dieses Beispiel zeigt, wie gut JAVA das Bewusstsein für Zeitzonen implementiert hat.
JAVA 7 Update 1 wurde am 18. Oktober 2011 veröffentlicht, der "Samoa-Fall" wurde hier nicht berücksichtigt. Oracle stellt jedoch ein Tool namens 1. TimeZone timeZoneAmsterdam = TimeZone.getTimeZone("Europe/Amsterdam");
2. SimpleDateFormat sdf = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss");
3. sdf.setTimeZone(timeZoneAmsterdam);
4. calendar = new GregorianCalendar(timeZoneAmsterdam);
5. calendar.set(1937, 5, 30, 23, 59, 59);
6. System.out.println(sdf.format(calendar.getTime()));
Die Ausgabe von Zeile 6 ist offensichtlich:
30-06-1937 23:59:59
Nun wenden wir den gleichen Trick wie beim "Samoa-Fall" an. Fügen Sie die folgenden Zeilen hinzu:
7. calendar.add(Calendar.SECOND, 1);
8. System.out.println(sdf.format(calendar.getTime()));
Frage: Was wird die Ausgabe von Zeile 8 sein?
Die richtige Antwort ist:
01-07-1937 00:00:28
Die kurze Geschichte dahinter: In den frühen 1900er Jahren erklärte die niederländische Regierung, dass die offizielle Zeit in den Niederlanden die "Amsterdamer Zeit" sei. Genauer gesagt, der Meridian des "Westertoren" in Amsterdam. Daraus ergab sich ein Versatz von 19 Minuten und 32 Sekunden zur GMT.
Am 1. Juli 1937 wurde beschlossen, dass der Versatz zur GMT 20 Minuten betragen sollte, was einen Unterschied von 28 Sekunden bedeutete. Offiziell gibt es also die ersten 28 Sekunden des 1. Juli 1937 in den Niederlanden nicht. Wahrscheinlich haben sich 1937 nicht so viele Menschen Gedanken über die möglichen IT-Folgen einer solchen Entscheidung gemacht.
Fazit
Mit diesem Artikel möchte ich Ihnen zeigen, dass Sie besonders in der IT-Branche mit Annahmen in Bezug auf Kalender- und Zeitzonenfragen vorsichtig sein müssen. Schwer zu erkennende Fehler können um die Ecke kommen, ohne dass Sie es merken. Wenn Sie beispielsweise einen Kalender für eine Datums-/Zeit-/Zeitzonen-Kombination erstellen, die nicht existiert, passiert Folgendes:
-
- JAVA gibt ein Datum zurück, das auf den nächsten gültigen Wert in der Zukunft "abgerundet" ist (wir haben dies in beiden Beispielen in diesem Artikel gesehen)
- Wenn Sie nicht möchten, dass JAVA in Zukunft den nächstgelegenen gültigen Wert zurückgibt, setzen Sie den Wert der Eigenschaft Lienient auf false. Dann erhalten Sie in Zukunft eine Ausnahme anstelle des nächstgelegenen gültigen Wertes.
</ul Wenn Sie also die interessanten Abweichungen in der Zeitzone, für die Sie Software entwickeln, nicht kennen, kann die Arbeit mit Kalendern und Daten zu unerwarteten Rückgabewerten oder Ausnahmen führen.
Verfasst von
Maarten Kennis
Unsere Ideen
Weitere Blogs
Contact