2008-09-30 5 views
6

Ich muss die Sommerzeit (Sommerzeit) Wechselregeln für verschiedene Weltregionen in einer Datenbank speichern. Ich habe bereits eine Möglichkeit, Regionen und Unterregionen zu speichern (so wird das ganze "half of Australia"/Arizona/Navaho Problem behandelt), aber ich frage mich, was das effizienteste Schema wäre, um dies zu erreichen. Die beiden Optionen, wie ich sehe sie:Wie können Sommerzeitregeln am besten dargestellt werden?

  • Haben Sie eine Tabelle, die für jedes Jahr und Region geben die Start- und Endzeiten für die Sommerzeit sowie die spezifische einzigartige eine Zeile enthält Offset
  • Haben Sie eine Tabelle, die Geschäfte eine Formel und effektiver Datumsbereich für jede Region (effektive Reichweite für Regionen wie Israel erforderlich)

der Vorteil für die erste Flexibilität, da buchstäblich etwas möglich ist. Unglücklicherweise erfordert es auch (a) mehr Platz und entsprechend (b) viel Arbeit, um die Dateneingabe zu erhalten. Die zweite ist schön, weil eine Zeile jahrzehntelang einer Region entsprechen kann, aber auch eine Art Parser und Interpreter für Sprachen in der Anwendungsebene benötigt wird. Da diese Datenbank von mehreren verschiedenen Anwendungen verwendet wird, die in Sprachen ohne leistungsfähige Textverarbeitungsfunktionen geschrieben sind, würde ich diese Route lieber vermeiden.

Ich würde gerne nur zoneinfo oder etwas ähnliches verwenden, aber das ist in diesem Fall leider keine Option. Genauso kann ich die Daten, die Zeitzone und die Sommerzeit nicht normalisieren. muss in der Datenbank sein, um bestimmte Anwendungsfälle zu erfüllen.

Hat jemand Erfahrung damit, etwas ähnliches zu tun? Hat jemand irgendwelche brillanten Optionen, die ich vielleicht verpasst habe?

+1

Ich denke, wir brauchen eine "DST" -Tag, fünfzig Prozent meiner Programmierung überwindet DST. –

Antwort

16

Sie sind ziemlich zu der ersten Option verdammt. Sie können Daten so weit vorausplanen, wie Sie möchten, für Länder, die bezüglich Zeitänderungen "Regeln" haben, aber in einigen Gebieten gibt es keine Regel, und die Änderungen werden entweder durch diktatorische Fiat oder durch legislative Abstimmung jährlich umgesetzt (Brasilien tat dies bis dieses Jahr).

Dies ist der Grund, warum alle OS-Anbieter Änderungen der Zeitzonen-Datei einmal oder zweimal pro Jahr ausführen - sie müssen, weil sie keine 100% genaue Datei programmatisch erzeugen können.

4

Wenn die DST-Regeln in der Datenbank enthalten sein müssen, würde ich sie wahrscheinlich automatisch von einer externen autorisierenden Quelle (Bibliothek, Website, was auch immer) aktualisieren. DST-Regeln manuell zu verwalten, klingt nicht nach viel Spaß.

1

Das Oracle DBMS erledigt dies automatisch für Sie. Das Datum wird in einer internen Repräsentation gespeichert (stellen wir uns UMT für das Argument vor) und wird nach den Regeln der Zeitzone formatiert, wenn es in einen String konvertiert wird.

Dies löst auch das Argument darüber, was während der Änderung im Laufe der Zeit zu tun ist. I.E. Wenn Sie die Uhr 1/2 Stunde zurückdrehen, gibt es tatsächlich 2 Instanzen von 3:25 Uhr am selben Tag.

2

Eine der besten Informationsquellen für Zeitzonenregeln ist die Olson-Datenbank, die unter elsie.nci.nih.gov verfügbar war. Im September 2008 war die aktuelle Version der Daten tzdata2008f.tar.gz, die aktuelle Version des Codes war tzcode2008e.tar.gz (und ja, der Code wurde nicht immer freigegeben, als die Daten vorhanden waren). Dies ist in der Regel die Informationsquelle für viele andere Systeme (einschließlich insbesondere der Oracle-Informationen). Es gibt auch eine Mailingliste. Wie Sie sehen können, gab es bisher sechs Versionen der Daten im Jahr 2008; Ich habe Kopien von 2005r, 2006l, 2007k, die auf meiner Maschine lauern, also können sich die Dinge ziemlich häufig ändern.

Heutzutage (März 2017) ist die Olson-Datenbank von IANA erhältlich - siehe https://iana.org/time-zones und ftp://ftp.iana.org/tz (speziell ftp://ftp.iana.org/tz/releases).

Es gibt auch das Common Locale Data Repository CLDR, das auch Informationen über Zeitzonen enthält.