Zeitumstellung zum Frühlingsanfang: Weiterentwicklung der Berechnung historischer Datums- und Uhrzeitwerte im Web

Zeitumstellung zum Frühlingsanfang: Weiterentwicklung der Berechnung historischer Datums- und Uhrzeitwerte im Web

Webentwickler möchten Anwendungen für den internationalen Markt entwickeln, um ein weltweites Publikum zu erreichen. In Internet Explorer 10 können Webentwicklern die historische Sommerzeit nutzen, die bereits über das zugrunde liegende Betriebssystem verfügbar ist. Hierdurch wird eine präzisere Interaktion von Apps und Websites über verschiedene Zeitzonen mit historischen Datums- und Uhrzeitwerten möglich.

Im letzten Jahr haben wir die zukünftigen Internationalisierungs-APIs für ECMAScript vorgestellt, die Funktionen wie die Darstellung von Währungen und den Zeichenfolgenvergleich unter Berücksichtigung des jeweiligen Gebietsschemas innerhalb der Webstandard-Plattform ermöglichen, Szenarien, für die bisher systemeigene Interoperabilität oder die Verwendung eines Plug-Ins erforderlich war. Im Rahmen dieser Bemühungen, die Webplattform für den internationalen Markt vorzubereiten, haben wir eine Demo veröffentlicht, mit der herausgefunden werden kann, wie Browser mit historischen Datums- und Zeitzoneninformationen umgehen.

Herausforderungen bei der Berechnung historischer Datums- und Uhrzeitwerte

Bei der Interaktion mit vergangenen Datumswerten, beispielsweise im Zusammenhang mit der Auswertung früherer Aktienpreise, Geburtstagen oder historischen Ereignissen, müssen Webentwickler häufig eine Validierung auf dem Server vornehmen. Entwickler sind vom Server abhängig, da derzeit an den Datumswerten vorgenommene Sommerzeitanpassungen von JavaScript-Modulen nicht so präzise durchgeführt werden wie durch die häufig auf Servern ausgeführten Plattformen, z. B. .NET, PHP/Perl und Java. Neben dieser Ungenauigkeit sind historische JavaScript-Datumswerte häufig nicht zwischen Browserplattformen interoperabel. Daher können Entwickler nicht auf zuverlässige Abhängigkeiten vertrauen, wenn es um in JavaScript generierte, auf Sommerzeit angepasste Datumswerte geht.

IE10 ist der erste Browser mit präziseren an die Sommerzeit angepassten Datumswerten, die mit den Änderungen am Abschnitt 15.9.1.8 der ECMAScript 6-Entwurfsspezifikation übereinstimmen. Wir haben die Funktionen der Webplattform anhand der Szenarien erweitert, in denen Webentwickler zur Erfüllung ihrer Aufgaben mit dem Server interagieren müssen. Wir untersuchten, wie JavaScript-Module historische Datumswerte interpretieren und an die Sommerzeit anpassen. Dabei bemerkten wir einen Mangel in der Spezifikation der ECMAScript-Standards, durch den eine genauere Sommerzeitanpassung in bestehenden JavaScript-Implementierungen verhindert wird. Wir haben in Zusammenarbeit mit dem ECMAScript Standards Committee eine Spezifikationsänderung vorgeschlagen, um dieses Problem in der nächsten Version der ECMAScript-Spezifikation zu beheben.

Kennenlernen der Test Drive-Demo

Um das Problem zu veranschaulichen und zu zeigen, wie Ihr bevorzugter Browser mit historischen Datumswerten umgeht, können Sie die Test Drive-Demo „Historic Dates“ ausprobieren. Klicken Sie im unteren Bereich der Demo auf ein beliebiges Symbol für ein Ereignis aus der Raumfahrtgeschichte. Daraufhin wird das historische Datum vom Browser gelesen, an dem das Ereignis stattfand, und Datum und Uhrzeit des Ereignisses werden unter Anwendung der Regel zur Sommerzeitanpassung angezeigt, die zum entsprechenden Zeitpunkt im Browser als Standardeinstellung festgelegt war. Die Demo überprüft anschließend, ob historisches Datum und Sommerzeit korrekt berechnet wurden oder nicht.

Im oben dargestellten Fall, wenn das historische Datum des IMAGE-Satellitenstarts angezeigt wird, ist IE10 (ausgeführt auf einem Windows 8-Computer in der Zeitzone „Pacific Standard Time“) nunmehr präzise in der Lage, das korrekte Datum und die genaue Sommerzeit für das historische Ereignis zu bestimmen.

Hinweis: Sommerzeit gilt nicht für alle Zeitzonen, und es gibt Zeitzonen, in denen die Sommerzeitregeln niemals geändert wurden. Wenn sich Ihr System gegenwärtig in einer dieser Zeitzonen befindet, sollten Sie die Zeitzone des Systems zu einer solchen zu ändern, in der Sommerzeitregeln bestehen, die sich im Laufe der Zeit geändert haben (z. B. „Pacific Standard Time“), und die Demo erneut auszuführen. Während IE10 die Änderung der Zeitzone des Systems sofort anwendet, müssen Sie, wenn Sie einen anderen Browser verwenden, diesen möglicherweise neu starten, damit die aktualisierte Zeitzone wirksam wird.

Verbesserte Handhabung historischer Datums- und Zeitwerte in IE10

Betrachten wir, wie die derzeitige ECMAScript-Spezifikation die Genauigkeit der Anpassung von Datumswerten auf Sommerzeit in JavaScript beeinflusst:

In Abschnitt 15.9.1.8 des ECMAScripts 5.1 wird festgelegt, dass für JavaScript-Implementierungen wie dem Chakra-Modul von Internet Explorer beim Umgang mit historischen Datumswerten grundsätzlich Folgendes gelten soll:

Die ECMAScript-Implementierung soll nicht bestimmen, ob die genaue Uhrzeit an die Sommerzeit angepasst wurde, sondern nur, ob Sommerzeit vorliegt, wenn zu diesem Zeitpunkt der aktuelle Sommerzeitalgorithmus verwendet wurde. Hierdurch werden Komplikationen vermieden; es müssen beispielsweise nicht die Jahre berücksichtigt werden, in denen in diesem Gebietschema die Sommerzeit ganzjährig galt.

Wenn in der Hostumgebung Funktionen zum Bestimmen der Sommerzeit zur Verfügung stehen, kann von der ECMAScript-Implementierung das fragliche Jahr einem ähnlichen Jahr zugeordnet werden (z. B. kein Schaltjahr und gleiche Jahresanfangswoche), für das die Hostumgebung Sommerzeitinformationen bereitstellt. Die einzige Einschränkung hierbei ist, dass alle ähnlichen Jahre zu den gleichen Ergebnissen führen müssen .

Das bedeutet, vereinfacht ausgedrückt: Eine JavaScript-Implementierung soll bei der Verarbeitung eines historischen Datums entweder den gegenwärtigen Sommerzeitalgorithmus darauf anwenden oder den Wochentag des 1. Januars des Jahres bestimmen, berechnen, ob es sich um ein Schaltjahr handelt, die gegenwärtigen Sommerzeitregeln für ein Jahr mit den gleichen Eigenschaften (in Bezug auf Anfangstag und Schaltjahr) ermitteln und die jeweilige Sommerzeit für das historische Datum verwenden. Als Beispiel für die letztgenannte Variante war 1972 ein Schaltjahr, das an einem Samstag begann. Das nächste an einem Samstag beginnende Schaltjahr war 2000. Gemäß der Sprachspezifikation können JavaScript-Implementierungen also zur Handhabung von Datumswerten aus dem Jahr 1972 entweder die aktuellen oder die Sommerzeitregeln für das Jahr 2000 anwenden.

Es bestehen zwei wesentliche Probleme, wenn eine der beiden oben genannten Regeln verwendet wird, um die Sommerzeitregeln für historische Datumswerte anzuwenden. Erstens sind die Sommerzeitregeln für eine bestimmte Zeitzone nicht konstant und ändern sich im Laufe der Zeit. Dies kann dazu führen, dass für ein historisches Datum die falschen Regeln angewendet werden. Zweitens sind Webanwendungen in Bezug auf Zeitzonen, für die sich Sommerzeitregeln im Laufe der Zeit geändert haben, nicht mehr in der Lage, für eine Übereinstimmung dieser historischen Datumswerte mit der entsprechenden Berechnung durch die Betriebssystemplattform zu sorgen, auf der sie ausgeführt werden. Entwickler sind daher häufig dazu gezwungen, solche Interoperabilitätsprobleme zwischen Webanwendungen und der jeweiligen Ausführungsplattform mithilfe von Hacks zu umgehen.

Wie bereits erwähnt, lässt die ECMAScript 5.1-Spezifikation in Abschnitt 15.9.1.8 bei Implementierungen in Bezug auf Sommerzeitanpassungen eine beliebige Ungenauigkeit zu, schränkt sie allerdings bei der anzustrebenden Genauigkeit ein. Dieses Verfahren ist nicht sehr eingängig und konnte sich in der Praxis nicht als Konsens für Browser durchsetzen. Anstatt das Offsetverhalten der Zeitzone wie in Abschnitt 15.9.1.8 einzuschränken, sollte „DaylightSavingsTA“ in der Spezifikation implementierungsabhängig belassen werden.

Unsere Tests zeigen, dass keine der bestehenden Browserimplementierungen (aktuelle Versionen) entweder vollständig das Verhalten einhält, das in den plattformübergreifenden Standards festgelegt wurde, oder beim Umgang mit Datumswerten die Sommerzeitanpassung fehlerfrei vornimmt. Im Folgende finden Sie einige Beispiele, die die Unterschiede innerhalb der „Pacific Time Zone“ in den USA veranschaulichen:

Datum	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
1.4.2000	420	420	420	420	420	420	480	480	480	420

Beachten Sie, dass Chrome, Firefox und Node in Bezug auf dieses Datum inkonsistent zwischen Betriebssystemen sind. Allerdings liegt tatsächlich fast jeder falsch, der tatsächliche Anpassungswert für die Sommerzeit war 480.

Datum	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
10.3.2011	480	480	480	480	480	480	480	480	480	480
10.3.2109	480	480	480	480	420	480	480	480	420	420

Beachten Sie, dass einige Umgebungen in Bezug auf dieses Datum erneut gegen ES5.1-Regeln verstoßen (diese beiden Jahre beginnen mit einem Dienstag und sind keine Schaltjahre), hier jedoch gibt es sogar Abweichungen auf einem einzelnen Betriebssystem (sowohl Windows als auch Mac).

Blick in die Zukunft

Ab Internet Explorer 10 verwendet das Chakra-Modul für die Konvertierung zwischen lokaler Zeit und UTC nunmehr die Sommerzeitinformationen von der Windows-Plattform, auf der der Browser ausgeführt wird. 

Nachdem wir das Spezifikationsproblem berichtet und gemeinsam mit dem ECMAScript Standards Committee an einer Präzisierung der nächsten Version der ECMAScript-Spezifikation gearbeitet haben, um eine interoperable und genauere Webplattform zu ermöglichen, zeigt der aktuelle Entwurf der ECMAScript 6-Spezifikation jetzt im Detail, wie die erweiterte Unterstützung für Sommerzeitregeln auf Datumswerte angewendet werden sollte, um präzisere Informationen zu generieren. IE10 ist der erste Browser, der dieser aktualisierten Spezifikation entspricht, und wir hoffen, dass zur Behebung dieser Probleme die Unterstützung in den nächsten Versionen anderer Browser ebenfalls erweitert wird, um Webentwicklern das Erstellen umfangreicher Anwendungen für den internationalen Markt zu ermöglichen.

Da die Webplattform weiter an Bedeutung zunimmt, ist umfangreiche Anwendungslogik, die unter anderem von Kalenderanwendungen, Tabellen, Projektverwaltungssoftware usw. verwendet wird, nunmehr häufig vollständig in JavaScript geschrieben. Um Entwicklern die Aufrechterhaltung der Kompatibilität zu ermöglichen, ist diese Änderung nur im Standardmodus von IE10 aktiviert. Wenn Sie historische Datumswerte in Ihren Webanwendungen berechnen möchten und über benutzerdefinierte Logik verfügen, um die Ungenauigkeiten der Browser zu umgehen, sollten Sie sicherstellen, dass die benutzerdefinierte Logik bei einem Upgrade der Webanwendungen für den Einsatz in IE10 weiterhin ordnungsgemäß funktioniert.

– Suresh Jayabalan, Programmmanager, JavaScript-Team