Ich habe eine Datenbank, die UTC (GMT + 0) Zeitstempel enthält. Hier ist das Problem: Sie beziehen sich auf Abrechnungsaktivitäten im Bundesstaat Indiana.Wie werden die historisch genauen lokalen Zeiten in Java zugeordnet, wenn sich die Zeitzonenregeln ändern?
Wie einige vielleicht wissen, Indiana ...
- nicht beobachten Sommerzeit überhaupt vor 2006 (die meisten der Zustand EST war das ganze Jahr).
- 2006 gewählt, um EST zu bleiben, aber zu beginnen, die Sommerzeit mit dem Rest der USA zu beobachten
- revidiert es ist Regeln in 2007; die US-Bundesregierung Änderungen an der Sommerzeit, damit die Start- und End-Regeln geändert
Da die Zeitstempel in dieser Datenbank Regierung Abrechnung Aktivität beziehen, ist es tatsächlich notwendig ist, die UTC zu haben-Zeitstempel als lokale Zeiten berichtet, die historisch sind genau, um die Auditing-Genauigkeit zu bewahren. Es gibt daher drei Szenarien, die nur für Indiana gelten: Zeitstempel vor 2006 verwenden einen völlig anderen Satz von Zeitzonenregeln als die zwischen 2006 und 2007, und die nach 2007 verwenden noch einen ganz anderen Satz von Zeitzonenregeln. Sie können sich vorstellen, dass diese Datenbank Aktivitäten für andere Länder als Indiana enthält, und so werden die Dinge noch komplizierter.
Die Java - Kalender - und TimeZone - API enthält keine Klassen, die es dem Programmierer erlauben, Objekte mit mehr als einem Satz von Zeitzonenregeln zu erstellen und sie nicht für die korrekte Zuordnung von UTC - Zeitstempeln zu historisch genauen Ortszeiten zu verwenden Insbesondere ändern sich die gültigen Zeitzonenregeln.
ich über Möglichkeiten nachgedacht habe, das Problem der Zuordnung zu historisch genauen Ortszeit in Gegenden mit wechselnder Zeitzone-Regeln zu adressieren ...
Die Datenbank aktualisiert werden, so dass UTC-Zeitstempel entlang gespeichert werden könnte mit dem lokalen Zeitversatz und einem Sommerzeitoffset. Das Problem hierbei ist, dass die Größe der Datenbank ein wenig zunimmt und wenn die vorhandene Datenbank groß ist, dann erfordert das Aktualisieren aller Tabellen möglicherweise einen erweiterten Offline-Wartungszyklus.
Die Datenbank könnte aktualisiert werden, so dass das bestimmte TimeZone-Objekt, das für diesen bestimmten Zeitstempel geeignet ist, mit jedem Zeitstempel gespeichert wird. Obwohl ich denke, dass TimeZone-Objekte ziemlich leicht sind, sehe ich, dass dies flexibler ist als die obigen, aber immer noch weniger wünschenswert, da es erfordert, dass ein Objekt für jeden Zeitstempel beibehalten wird.
Es kann eine benutzerdefinierte API entwickelt werden, die ein geeignetes TimeZone-Objekt aus einer Datenbank mit historisch korrekten Regeln für die relevanten Locales erstellt. Diese Lösung ersetzt den erhöhten Speicherbedarf der beiden vorherigen Lösungen durch zusätzliche Verarbeitungsschritte. Jeder Zeitstempel, der angezeigt werden müsste, würde bedeuten, ein neues Objekt zu erstellen ... oder zumindest mit einem geeigneten Objekt aus einem Objekt-Pool zu paaren. Außerdem bedeutet das Erstellen und Verwalten einer Zeitzonendatenbank.
Die Grenzen der Java-Zeit und Kalender-API haben eine elegante Lösung für dieses Problem zu finden, wirklich schwieriger, als es sollte zum Beispiel abfragen, es ein bestehendes Objekt Simple sein (man kann nicht gemacht, und fragen, was Daylight Sparregeln folgt, ohne einen wirklich chaotischen Code zu schreiben).
Ich möchte nur fragen, ob jemand anders schon einmal mit einer solchen Situation umgegangen ist und wie sie damit umgegangen sind.
nicht wissen, Java, aber ich bin mir ziemlich sicher, dass es die [Olson Zeitzone-Datenbank] verwendet (http://www.iana.org/time-zones) (wie durch den Inhalt des [tzdata belegte -java Debian-Paket] (http://packages.debian.org/squeeze/tzdata-java)) Wenn ja, hast du nicht du musst dir Sorgen machen. Die Olson-Datenbank behandelt alle historischen Regeln und sollte Ihnen die korrekte Ortszeit geben. – Celada
Es ist so traurig, dass wir hart arbeiten müssen, um die Craps der Politiker zu bereinigen. – irreputable