Android: Zeitzonen

Von e7 am 26.08.2010, 18:54 in der Kategorie Code-Snippets mit den Tags sommerzeit zeitzone java android. Kompletten Eintrag zeigen

Mein CalDav-Projekt schreitet weiter voran. Im Moment kämpfe ich ziemlich mit Zeitzonen und anderen Dingen — was bspw. bei mehrtägigen Terminen sehr unschöne Verhaltensweisen zeigt und auch sonst ist eine Verschiebung um zwei oder vier Stunden unschön.

Android scheint Termine grundsätzlich als UTC zu speichern und keine alternativen Möglichkeiten vorzusehen. An sich keine schlechte Idee, außerdem würde es erklären, warum man beim Termin speichern keine Zeitzonen angeben kann, ohne dass man mit Exceptions bombardiert wird.

Momentan löse ich die Problematik folgendermaßen: Am Anfang benötige ich die UTC-Zeitzone, die wird auch als Default gesetzt.

tz_utc = TimeZone.getTimeZone(„UTC“);
TimeZone.setDefault(tz_utc);

Damit kann ich zumindest alles, was UTC ist (hat ein Z am Schluss), einfach verwursten. Termine, die nicht als UTC gespeichert sind, sind im iCal-Format einigermaßen leicht zu unterscheiden:

Beispiel UTC: DTSTART:20100627T140000Z
Beispiel ME(S)Z: DTSTART;TZID=Europe/Berlin:20100809T110000

Ich hoffe mal, dass das so von den Clients konsequent durchgehalten wird, vermute aber eher nicht. Es gibt im Standard noch ein BEGIN:VTIMEZONE, in dem bspw. Sunbird Dinge reinschreibt, die aber erst mal nicht relevant sind. Möglicherweise ist das auch nur das Gegenstück zu dieser misteriösen eventtime von Android, alternativ könnte es auch sein, dass das auch gilt, wenn bei DTSTART nix angegeben ist. Da muss ich mal bei Gelegenheit noch im Standard nachlesen.

Zum Umwandeln jedenfalls setz ich die entsprechende Zeitzone auf bspw. Europe/Berlin, erzeuge das Datum und setze die Zeitzone wieder zurück auf UTC. Anschließend kann ich das Offset draufrechnen/abziehen:

tz = TimeZone.getTimeZone(tzName);
TimeZone.setDefault(tz);
d = mkCaldavDateString(s);
l = d.getTime();
TimeZone.setDefault(tz_utc);
d = new Date(l — tz.getOffset(d.getTime()));


Leider hat ein Date kein .setTimeZone oder so, mit dem man das einfacher hätte machen können. Vielleicht hab ich das allerdings auch übersehen. Ich merks mir einfach mal vor für spätere Optimierungen :) Das mit der Rechnerei ist jedenfalls sehr unschön und ich werd versuchen, da noch ne saubere Lösung zu finden.