Ich versuche, eine Tabelle aus einer Datenbank zu extrahieren und sie in eine andere Art von Datenbank neu zu laden. Das Problem ist, dass das Datum 1. Juli 1937 mit meinen lokalen Einstellungen ein Problem darstellt, den Zeitstempel zu bekommen, wenn es 00:00:00 ist. In den Niederlanden änderten sie 1937 die Meridiane, so dass die ersten 28 Sekunden vom 1. Juli 1937 nicht existierten.
Wenn ich das Datum in einen Kalender einlese, um die Ausgabe neu zu formatieren, ändert sich die Zeit entweder auf 28 Sekunden vor dem Datum; 30. Juni 23:59:32 oder 1. Juli 00:00:28 (abhängig vom Fahrer) Kennt jemand eine Abhilfe für dieses Problem?
Konfigurieren Sie Calendar so, dass ein anderes Locale verwendet wird.
Calendar s übersetzt die codierte Zeit in die lokale Zeit. Diese mehr als 20 Sekunden existieren nicht mit verschiedenen Anzeigeformaten in Locale . Wenn Sie also darauf bestehen, dass Locale beibehalten wird und Sie darauf bestehen, Daten mit so festgelegten Sekunden anzuzeigen, dann müssen Sie das mit den Niederländische Regierung im Jahr 1937; Wenn Sie jedoch die Anzeigeformatierung auf eine andere Locale ändern, stellen Sie fest, dass der tatsächliche Wert der zugrunde liegenden Zeitdatenstruktur nicht geändert wurde. In Gebietsschemas mit unterschiedlichen Sekundenwerten wird die Auflösung zu unterschiedlichen Zeiten aufgelöst .
Wenn Sie die Zeit zwischen Lesen und Speichern manipulieren, können Sie versehentlich ein neues Objekt Time oder Calendar erstellen, das die zugrunde liegenden Datenstrukturen basierend auf einer Übersetzung von Die Locale formatierte Zeit in die zugrunde liegende Datendarstellung.
Aus diesem Grund ist es am besten, die Verarbeitung von Großdatum und -zeit in UTC ohne Tageslichteinsparungen zu handhaben. Auch wenn die Zeiten nicht mit den lokalen Zeiten übereinstimmen (und für Menschen in verschiedenen Zeitzonen schwieriger zu lesen sind), gibt es jede Sekunde von UTC, so dass einfache Änderungen von +5 Sekunden schnell durch eine einfache Formatierung der Auswirkungen verifiziert werden können Zeit.
Der einzige Nachteil bei dieser Art der Handhabung ist, dass Sie später die UTC-Zeit immer in die lokale Zeit für die Anzeige zurückübersetzen müssen. Abhängig von der Bildung Ihrer Zuhörerschaft könnten einige Holländer schockiert sein zu sehen, dass ihre Regierung solche Sekunden nicht zulässt und verlangen könnte, dass sie trotz der Entscheidungen angezeigt werden, dass solche Sekunden nicht Teil des niederländischen Kalenders sind / p>
Warten Sie einfach, bis Sie 1582 die fehlenden Tage entdecken.
In Java wird ein Datum zeitzonenunabhängig gespeichert. (Es wird als die Anzahl der Millisekunden seit - Ich vergesse das Startdatum, war es 1. Januar 1970 GMT?) Wenn Sie ein Datum ausgeben, DANN muss es die Zeitzone berücksichtigen. Aber jede interne Manipulation sollte keine Rolle spielen. Sie haben nicht angegeben, welche Datenbank-Engine Sie verwenden, daher weiß ich nicht, wie sie Daten speichert. Ich arbeite heutzutage hauptsächlich mit Postgres, die alle Daten in GMT speichert und zur Ein- und Ausgabezeit in und aus der entsprechenden Zeitzone konvertiert.
Wenn Sie also Ihre Zeitzone auf GMT einstellen, sollten alle Änderungen zum Verschieben von Zeitzonengrenzen, Sommerzeit usw. irrelevant sein.
Versuchen Sie, die Daten in GMT oder UTC zu extrahieren und laden Sie sie dann auf diese Weise zurück. Dann verwenden Sie die Details des neuen Systems für das Gebietsschema und nicht das ursprüngliche System.