Ich habe eine schreckliche Zeit (kein Wortspiel beabsichtigt) mit DateTime-Vergleich in meinem aktuellen Projekt, speziell zwei Instanzen von ActiveSupport :: TimeWithZone zu vergleichen. Das Problem ist, dass beide TimeWithZone-Instanzen denselben Wert haben, aber alle Vergleiche zeigen an, dass sie unterschiedlich sind.
Wenn ich während der Ausführung zum Debuggen (mit RubyMine) pausiere, kann ich folgende Informationen sehen:
%Vor%Ein Vergleich zeigt jedoch, dass die Werte nicht gleich sind:
%Vor%Die nächste Antwort, die ich bei der Suche gefunden habe ( Vergleich zwischen zwei ActiveSupport :: TimeWithZone-Objekten schlägt fehl ) zeigt das gleiche Problem hier an, und ich habe versucht, die Lösungen, die ohne Erfolg anwendbar waren (versuchte db: test: vorbereiten und ich Spring nicht ausführen).
Auch wenn ich versuche, in explizite Typen zu konvertieren, sind sie beim Vergleich immer noch nicht gleichwertig.
to_time:
%Vor%to_datetime:
%Vor% Die only "Lösung", die ich bisher gefunden habe, besteht darin, beide Werte mit to_i zu konvertieren, dann zu vergleichen, aber das ist extrem umständlich zu programmieren, wo immer ich Vergleiche machen möchte (und außerdem scheint, dass es unnötig sein sollte):
Jeder Rat würde sehr geschätzt werden!
Wie von Jon Skeet oben erwähnt, war der Vergleich wegen versteckter Millisekunden-Differenzen in den Zeiten fehlgeschlagen:
%Vor%Diese Entdeckung führte mich auf einen seltsamen Weg, um endlich herauszufinden, was letztendlich das Problem verursacht hat. Es war eine Kombination dieses Problems, das während des Testens und nur unter Verwendung von MySQL als Datenbank auftritt .
Die Probleme wurden nur beim Testen angezeigt, weil ich innerhalb des Tests, bei dem dies auftrat, einige Tests mit einigen verknüpften Modellen, die die obigen Felder enthalten, durchgeführt habe. Die Instanz eines Modells muss während des Tests in der Datenbank gespeichert werden - das Modell, das den Wert timestamp enthält. Das andere Modell führte jedoch die Verarbeitung durch und referenziert somit die Instanz seiner selbst, die im Testcode erstellt wurde.
Dies führte zu dem zweiten Schuldigen, nämlich der Tatsache, dass ich MySQL als Datenbank verwende, die beim Speichern von datetime -Werten nicht Millisekunden-Informationen speichert (anders als etwa PostgreSQL). .
Dies bedeutet immer, dass die Variable timestamp , die nach dem Abrufen von ActiveRecord aus der MySQL-Datenbank gelesen wurde, effektiv von den Millisekunden-Daten gerundet und rasiert wurde, während die Variable started_at einfach im Speicher gehalten wurde Während des Tests und somit waren die ursprünglichen Millisekunden noch vorhanden.
Meine eigene (untergeordnete) Lösung besteht darin, beide Modelle (und nicht nur eine) im Test dazu zu zwingen, sich selbst aus der Datenbank zu holen.
TLDR; Wenn möglich, benutze PostgreSQL, wenn du kannst!
Tags und Links ruby datetime ruby-on-rails comparison