FFD'S NEUES TECH&SCIENCE-BLOG

Zeitangaben auf Websites: Welche Zeitzone?

Im deutschen Sprachraum gibt es nur eine Zeitzone, deswegen sind Zeitangaben auf deutschen Websites eine eindeutige Angelegenheit: alles bezieht sich auf die Mitteleuropäische (Sommer-)Zeit. Englischsprachige Websites sind da schon viel problematischer. Allein die USA haben vier Hauptzeitzonen, dazu kommen Alaska und Hawai. Websites von amerikanischen Fernsehsendern bieten einen Zeitzonenselektor an.

Für eine internationale Website könnte ein brauchbare Zeitzonenselektor in etwa so aussehen:

     All times are GMT. Change Timezone

Geht das für den Nutzer auch bequemer? Weltweit gibt es schließlich 40 Zeitzonen, die zur Auswahl gestellt werden müssen, unter anderem Exoten wie GMT+8:45 in einer westaustralischen Region mit gerade mal 200 Einwohnern. Dazu kommt die unübersichtliche regionale und von Jahr zu Jahr wechselnde Handhabung von Sommerzeit, mit teilweise dramatischen Konsequenzen, wie etwa in Israel:

In territories controlled by the Palestinian National Authority, daylight saving time [Sommerzeit] ends later, which can lead to some confusion. On September 5, 1999, terrorists were transporting a bomb that they mistakenly thought was set to go off at 17:30 Israel Standard Time; it was actually set for 17:30 Palestinian Daylight Time, which was an hour ahead. As a result, the bomb went off while the bomb was still being transported, killing the terrorists. (Wikipedia)

Zurück zur virtuellen Welt: Leider schickt der Internet-Browser nicht die auf dem Client eingestellte Zeitzone zum Webserver, so wie das bei der Sprache passiert. Der Webserver kann automatisch die richtige Sprache auswählen, aber nicht die richtige Zeitzone (es sei denn, er versucht eine geographische Auswertung der IP-Addresse, was aufwändig und unzuverlässig ist).

Interessanterweise ist es aber in Javascript möglich, die Zeitzone herauszufinden, also nachdem die Seite vom Server auf den Client übertragen wurde:

new Date().getTimezoneOffset()

gibt -120 zurück, also die Zeitverschiebung zu GMT in Minuten. Eine naheliegende Strategie ist daher folgende:

Ein Javascript speichert die Zeitzone in einem Cookie, welches der Server ausliest, um die Zeitzonen-Transformation serverseitig durchzuführen.

Diese Strategie leidet offensichtlich unter einem Henne-Ei-Problem: Das Cookie kann erst erzeugt werden, wenn die erste Seite bereits geladen ist, so daß Zeitangaben dieser ersten Seite nicht transformiert werden können.

Gravierender ist aber die fehlende Berücksichtigung der Sommerzeitumstellung. Enthält die Seite eine zukünftige Zeitangabe, und zwischen der Auslieferung der Seite und dem angegebenen Zeitpunkt liegt eine Umstellung auf Sommerzeit (oder zurück), wird sie falsch dargestellt. Der Zeitpunkt der Sommerzeitumstellung kann in Javascript nicht explizit abgefragt werden.

Vorzuziehen ist daher die clientseitige Transformation:

Der Server liefert die Zeit unabhängig von der Zeitzone aus (zum Beispiel immer in GMT), und ein Javascript wandelt diese nach dem Laden der Seite in Zeitangaben in der lokalen Zeitzone um.

Dazu kann die Zeitangabe in HTML mit zusätzlichem Markup* versehen werden:

<object class="timestamp">
	09.07.2009 15:03
	<param name="time" value="2009-07-09T15:03:17+02:00"/>
<object>

Nach dem Laden der Seite durchläuft ein Javascript dann sämtliche markierte Zeitangaben, wertet den zusätzlichen Parameter mit maschinenfreundlicher Zeitangabe im ISO-Format aus, und ersetzt dann den vorgegebenen Text durch die in der lokalen Zeitzone berechneten, menschenfreundliche Zeitangabe. Realisiert mit dem populären Javascript-Toolkit Dojo könnte das so aussehen:

dojo.query("object.timestamp").forEach( function(node) {
	var isoTime = dojo.query("param[name='time']", node)[0]
		.getAttribute("value");
	var machineTime = dojo.date.stamp.fromISOString(isoTime);
	var humanTime = dojo.date.locale.format(time);
	node.innerHTML = humanTime;
});

Hier sorgt die Javascript-Datumsbehandlung dafür, daß auch die Sommerzeitumstellung korrekt berücksichtig wird.

*) Mögliche Markup-Alternativen zum <object/>-Tag werden in "A Survey of HTML Annotation Methods" diskutiert. Erst in HTML 5 gibt es eine standardisierten Weg, Daten in HTML einzubinden: "HTML 5 data- Attributes".

Verkannte Informationsspeicher: Die Junk-DNA

Wissenschaftliche Theorien haben einen Lebenszyklus. In die Welt gesetzt werden sie von einer Handvoll Revolutionäre, später etablieren sie sich, und irgendwann werden sie - gegen den massiven Widerstand des akademischen Mainstreams - abgelöst durch eine neue Theorie, wodurch sie nicht falsch werden, aber ihr Gültigkeitsbereich signifikant zurechtgestutzt wird. Thomas Kuhn hat dafür 1962 den Begriff Paradigmenwechsel geprägt (in seinem sehr lesenswerten Buch "Die Struktur wissenschaftlicher Revolutionen").

Ein solcher Paradigmenwechsel findet derzeit in der Genetik statt, ausgelöst durch die Resultate des"Humane Genome Project", der 2003 abgeschlossenen Sequenzierung des menschlichen Erbguts. Wir kennen das 40 Jahre alte Paradigma der Genetik aus der Schule: die DNA besteht aus Sequenzen von Basen (A, C, U und G). Eine zusammengehörende Basen-Sequenz heißt Gen und codiert ein Protein. Bis auf ein paar Ausnahmen, die es in der Biologie immer gibt, ist dies der alles entscheidende Mechanismus, die Blaupause aller Lebewesen.

Nun stellte sich im Laufe der Zeit heraus, daß ein nicht unbeträchtlichter Teil der DNS ungültige Sequenzen enthalten, die keine Proteine codieren können. Beim Menschen sind dies tatsächlich sogar 95% der gesamten DNS. Statt nun ihre Theorie zu hinterfragen, wurden diese Teile der DNS von der Zunft der Molekularbiologen zu "evolutionärem Schrott" (englisch: Junk-DNA) erklärt. 

Das Humane Genome Projekt fand darüberhinaus sehr viel weniger Gene als erwartet. Klassische Lehrbücher schätzten die Anzahl der menschlichen Gene auf 100.000. Tatsächlich waren es gerade mal 25.000 - etwas mehr als beim Fadenwurm, und weniger als bei einem Unkraut mit dem traurigen Namen Ackerschmalwand. Ein Großteil dieser menschlichen Gene ist mit denen der nächsten Verwandten des Menschens identisch (für den Schimpansen habe ich die Zahlen 98,7% und 99,4% gefunden). Die notwendige Schlußfolgerung: der Mensch ist praktisch ein Affe, und zum nicht unbeträchlichen Teil ein Fadenwurm. So wenigsten las man es dann in der einschlägigen Presse.

Tatsächlich aber vermuteten einige kühlere Köpfe, daß der Hase anderswo begraben liegt: nämlich in der 95% unverstandenen DNS, dem "evolutionären Schrott", der Junk-DNA. Was wäre, wenn sie tatsächlich von Bedeutung ist? Die Hinweise darauf haben sich inzwischen verdichtet. Es gibt aber noch weitergehende Thesen. 

Die radikale These stützt sich auf folgende Beobachtung. Einzeller, wie zum Beispiel Bakterien, haben 0% Junk-DNA. Je komplexer die Organisation, desto größer ist der Anteil der Junk-DNA: 65% bei Pflanzen, 70% bei Wirbellosen, bis zu 90% bei höheren Tieren, und 95% beim Mensch. Wenn das kein Wink mit dem Zaunpfahl ist? Die These ist, daß die geschmähte Junk-DNA den Bauplan des Vielzellers enthält. Jede Zelle eines Vielzellers hat ja die gleiche DNS, und daher auch den gleichen Satz von Proteinen zur Verfügung. Wo ist die Information gespeichert, die die Ausprägung der Zellen bestimmt - werde ich eine Nervenzelle oder ein weißes Blutkörperchen - und wie die Zellen zu Organen und zum ausgewachsenen Organismus zusammengesetzt werden? Dieser fundamentale Informationsspeicher sitzt wohl in der Junk-DNA, auch wenn man die zugrundeliegenden Mechanismen noch nicht versteht. 

Für mich ist das sehr schlüssig, und hat eine gehörige Portion Ironie. Man hat vor lauter Bäumen den Wald nicht gesehen. Aber ich bin nicht vom Fach, und sollte ein Experte diesen Artikel lesen, bin ich für weiterführende Hinweise dankbar. Mein Halbwissen basiert größtenteils auf der Lektüre von  "Spektrum der Wissenschaft Dossier: Das neue Genom".

Mit der Google App Engine in die Cloud

Für ein kleines Hobbyprojekt habe ich als Plattform die Google App Engine ausgewählt, wegen der bewunderswerten Radikalität und Modernität ihres Ansatzes. Im Gegensatz zum Cloud-Konkurrenten Amazon Web Services arbeitet man hier in einer völlig virtuellen und verteilten Umgebung - man sieht also nichts vom zugrundeliegenden Betriebssystem oder gar der Hardware. Und warum soll man sich auch mit Datenbankkonfiguration auf Systemlevel herumschlagen? Stattdessen freue ich mich, daß meine Daten in der wohl skalierbarsten Datenbank der Welt liegen, ohne daß ich einen Finger dafür heben muß. Kontrolle muß ich dabei allerdings durch Vertrauen ersetzen, was ein Riesenhaken ist. In einem späteren Beitrag mehr dazu.

Programmiersprachen sind Java oder Python. Google stellt mir eine komplette Servletumgebung zur Verfügung, und ich kann per File-API lesend auf meine Resourcen zugreifen (wie etwa Konfigurationsdateien oder Templates), über die Java-APIs JPA (=EJB3) oder JDO auf die Datenbank zugreifen. JDBC ist nicht, weil die zugrundeliegende Datenbank ist nicht relational. Außerdem gibt es weitere Services für E-Mail, Aufruf von externen Services per http, Bildverarbeitung und einen verteilten Cache. 

Threads dürfen nicht erzeugt werden, und jeder Request muß innerhalb 30 Sekunden abgearbeitet werden. Damit läßt sich aber schon wunderbar eine übliche Webanwendung basteln. Ich habe meine Lieblingsframeworks (Guice, Facelets) auch gleich ohne größere Probleme zum Laufen gebracht. Und die hohe Skalierung bekommt man quasi out-of-the-box. 

Wunderschön ist die Eclipse-Integration. Es gibt einen absolut brauchbaren Projekt-Wizard, und dann kann ich das ganze per Knopfdruck deployen. Und jetzt fällt es mir schwer, nicht ins Schwärmen zur verfallen, und stattdessen lasse ich die Bilder sprechen, um genauer zu sein, einen Screenshot von der Admin-Console der App-Engine, der in echt Googlescher Schlichtheit daher kommt:

Es werden alle hochgeladenen Versionen meiner Anwendung angezeigt, die ich allesamt, vergangene und aktuelle, live testen kann, durch Klick auf den angegebenen Link. Per Radiobutton wähle ich die Version aus ("Default"), die auf meiner Domain ausgeführt wird. Per Knopfdruck kann ich zwischen den Versionen zappen... ist das nicht ein Traum? ... Hoppla, fragt da jemand nach der Datenbankversionierung? Dazu später mehr.

Vorhang auf!

Ich erfülle mir jetzt den lang gehegten Wunsch, abseits unseres offiziellen Firmenblogs ungeschminkt und spontan über Technologie und angrenzende Themengebiete zu schreiben. In Deutsch, mit Anglizismen und Fachbegriffen durchsetzt. Auch wenn ein anständiges Techblog in Englisch sein sollte, was mir aber zu anstrengend und verkrampft wäre. 

Worum geht's? Software-Entwicklung im Zeitalter des Cloud Computing. Die Wirkungskette Technologie und Wissenschaft -> Innovation -> Business und die Rolle der Menschen dahinter. Geschichtliche Entwicklungen. Ein buntes Sammelsurium halt. Viel Spaß beim Lesen!