2009-06-29 10 views
11

Gibt es eine Möglichkeit, den Versatz von GMT (oder Zeitzone) von einer geografischen Länge/Breite zu schätzen? Ich habe Geonames gesehen, aber das müsste langfristig funktionieren und wir wollen uns nicht wirklich auf einen Webservice verlassen. Es würde nur verwendet werden, um zu bestimmen, ob "heute" oder "heute Abend" angezeigt werden soll, wenn Informationen an verschiedene Benutzer gegeben werden, so dass es nicht zu genau sein müsste (ein oder zwei Stunden wären nicht schlecht).Grobschätzung des Zeitversatzes von GMT aus Längengrad

Antwort

23
offset = direction * longitude * 24/360 

wo Richtung 1 für Osten, -1 für Westen und Länge ist in (-180.180)

+0

Das ist ziemlich cool, dachte nicht, dass es so einfach wäre, aber bis jetzt scheint es ziemlich genau zu sein. Danke. – ravun

+1

@ravun, das ist richtig, wenn man bedenkt, dass a) die Erde 360 ​​Grad Länge hat und b) sich innerhalb von 24 Stunden um 360 Grad dreht. (-: –

+0

Es ist * vernünftig * richtig, wenn man bedenkt, dass die Zeitzonengrenzen normalerweise an Ländergrenzen gesetzt werden. Ansonsten müsste ich meine Uhr jeden Tag einstellen, wenn ich zur Arbeit gehe und wieder nach Hause gehen :-) Auch Sommerzeit Die Zeit hängt von der lokalen Gesetzgebung ab. Aber für die heute/heute Abend Frage sollte es ausreichen. – balpha

1

die Zeitzone Basierend auf die allein Länge ist wild ungenau außerhalb von internationalen Gewässern. Sehen Sie die Karte auf dieser Seite:

http://askgeo.com/database/TimeZone

Die vertikalen farbigen Streifen im tiefen Ozean sind die sogenannten natürlichen Zeitzonen von Länge abgeleitet allein, und die Farben des Landes sind die tatsächlichen Zeitzonen pro die Gesetze regeln. Sie können sehen, dass sie sich nicht sehr gut aufstellen.

Ich stieß tatsächlich auf dieses Problem, während ich an einem anderen Projekt arbeitete und umfangreiche Forschung und Entwicklung daran betrieb. Zuerst meine Forschung:

  • Erstens, Zeitzonen sind nicht in der Regel nur durch einen Offset von GMT (alias UTC) codiert. Dies berücksichtigt nicht die Sommerzeit und Änderungen in den Zeitzonen im Laufe der Jahre. Stattdessen werden Zeitzonen-IDs verwendet, um ein geographisches Gebiet zu bezeichnen, in dem die offizielle Uhrzeit für eine bestimmte Zeitperiode (z. B. seit 1970) über den gesamten Bereich gleich gewesen ist. Das wichtigste System solcher IDs ist die "Olson-Zeitzonen-ID" (zusammen sind diese IDs und ihre Offset-Regeln als "tz-Datenbank" bekannt), die von Linux und anderen Unix-Betriebssystemen verwendet wird. Die meisten Programmiersprachen und Betriebssysteme unterstützen native oder Drittanbieter-Unterstützung für Olson-Zeitzonen-IDs.

Im Hinblick auf die bestehenden Lösungen geografische Breite und Länge der Zeitzone zu konvertieren:

  • GeoNames.org hat eine große Datenbank von Punktstellen (Zentren der Städte, Flughäfen, öffentliche Gebäude, etc.) Jedes dieser Elemente ist mit einer Reihe nützlicher Metadaten versehen, einschließlich der Olson-Zeitzonen-ID. Und sie haben eine nette API, mit der Sie über das Internet darauf zugreifen können. Das Problem ist, dass, wenn der Punkt, den Sie abfragen, direkt über einem Datensatz in der Datenbank steht, Sie möglicherweise ein Ergebnis erhalten, das auf der anderen Seite eines Zeitzonenrands liegt, oder Sie erhalten möglicherweise keine Antwort auf Ihre Abfrage ist weit von ihrem nächsten Punkt entfernt. Der Web-Service ist auch schmerzhaft langsam und sie begrenzen die Anzahl der Abfragen, die Sie an einem Tag zu einer relativ kleinen Anzahl machen können.

  • Earth Tools (http://www.earthtools.org/webservices.htm) hat auch einen Dienst dafür, und es ist viel schneller als GeoNames, aber es gibt nur einen Offset von GMT zurück, keine Zeitzone ID, und die Sommerzeit wird für die meisten Länder nicht korrekt gehandhabt. Außerdem scheint es nicht gepflegt zu werden, daher bin ich mir nicht sicher, ob die Daten korrekt sind (Zeitzonen ändern sich im Laufe der Zeit).

Nachdem diese Optionen zu überprüfen und nach anderen Möglichkeiten ohne Erfolg suchen, habe ich beschlossen, meine eigene Lösung zu bauen, und freigegeben es an:

http://askgeo.com

AskGeo basiert auf einer Zeitzonenkarte der Welt, so gibt es eine gültige Zeitzone für jeden gültigen Längen- und Breitengrad zurück. Es gibt die Standard-Olson-Zeitzonen-ID (z. B. "America/Los_Angeles") zurück, die unter Linux und den meisten anderen Betriebssystemen und Programmierframeworks verwendet wird. Es gibt auch den aktuellen Offset zurück, wobei die Sommerzeit voll berücksichtigt wird.

Es ist extrem einfach zu bedienen und die Verwendung ist auf der Hauptseite der Website dokumentiert. Die API unterstützt Batch-Abfragen. Wenn Sie also viele Suchvorgänge durchführen müssen, verwenden Sie die Batch-Schnittstelle, anstatt unsere Server mit seriellen Anfragen zu blockieren. Die Massenabfragen sind auch viel schneller, also gewinnt jeder.

Als wir das erste Mal gestartet haben, haben wir es auf Google App Engine (GAE) erstellt und es allen Benutzern kostenlos zur Verfügung gestellt. Dies war möglich, weil die Preise von GAE zu diesem Zeitpunkt so niedrig waren. Seitdem hat sich unsere Serverlast erheblich erhöht und die GAE-Preise sind gestiegen. Beide Faktoren führten dazu, dass wir zu Amazon Web Services wechselten, um Hosting zu betreiben und die Gebühren für kommerzielle Zwecke zu erheben, während wir den Service für gemeinnützige, nichtkommerzielle Open-Source-Projekte und Forscher kostenlos bereitstellten. Für kommerzielle Nutzer bieten wir 1000 kostenlose Abfragen, damit potenzielle Kunden die API bewerten können, um sicherzustellen, dass sie ihren Anforderungen entspricht. Preise und Bedingungen finden Sie auf der Website.

Die zugrunde liegende Bibliothek wurde in Java geschrieben und aufgrund der großen Nachfrage haben wir die Bibliothek auch unter einer kommerziellen Lizenz veröffentlicht. Die vollständige Dokumentation der Bibliothek und Preisinformationen finden Sie auf der Website.

Ich hoffe, das ist nützlich. Es war sicherlich nützlich für das Projekt, an dem ich arbeitete.