Celui-ci me conduit noix !! Les données sont stockées correctement dans la DB (SQLite3). Toutefois, lorsque j'affiche la date à partir de l'enregistrement, les rails apparaissent à le contraire au 1/1/2000 - avec le temps correct. En d'autres termes, si je précise cela à la date de la date: 31 décembre 2009 18h00, SQLLITE3 sera en fait montrer en 2009-12-31 18:00:00. Mais .... Les rails afficheront la valeur du 1er janvier 2000 à 18h00 (en gardant la bonne heure).
J'ai créé des attributs virtuels pour gérer le formatage de la date (qui semblent fonctionner correctement). Et, j'ai mis mon fuseau horaire à: Je dois croire que c'est quelque chose de simple ... il me conduit totalement des noix !! Merci! John
3 Réponses :
Eh bien ... j'ai trouvé le problème. Comme il s'est avéré, lorsque les rails ont créé la table, il l'a fait à l'aide du type de données de temps. Alors que la date de la valeur d'une valeur DateTime sera stockée dans un champ d'heure, elle apparaîtrait que lors de la lecture d'un champ de temps, les rails ne considèrent que la partie temporelle.
Le correctif .. En désespoir, j'ai modifié la colonne pour être de type DateTime. Cela corrigé-le.
Jean
J'avais ce problème aussi. Pour ajouter des informations sur le problème: - dans une balise de débogage (<% = objet de débogage%>), l'heure et la date étaient correctes, mais lors de l'utilisation sans débogage (<% = objet.year%>), l'année était de 2000.
On peut s'attendre à une des deux choses:
xor
En réalité, les rails prennent les deux options. IMHO, c'est un bug. Ai-je raison? Ou je ne vois pas un point de la conception des rails?
J'ai eu le même problème, à l'aide de Postgres, et merci à User145110 pour la suggestion d'utiliser la classe DateTime au lieu de temps. Cela a fonctionné pour moi. J'ajouterais seulement que je devais changer ma migration pour utiliser DateTime, je pouvais toujours utiliser le temps et ses méthodes dans des tests comparés contre les valeurs DateTime. En d'autres termes, avec cette migration originale: ... et l'affectation d'échantillon utilisant le temps: ... il a sauvegardé ok , mais après la lecture plus tard, l'année a été changée en 2000. Peut-être que c'est un vieux bug y2k. MDR. Au lieu de cela, j'ai simplement changé la migration: .. et tout mon code a fonctionné. Même des attributions comme ce travail: Je ne peux pas m'empêcher de me sentir comme si je manque quelque chose, cependant. Est-ce que d'autres utilisent le temps de manipuler les dates?
C'est probablement causé par vos attributs virtuels. Pouvez-vous poster du code?
Je peux ... Sauf que cette question a été déroulée avant de mettre en œuvre les attributs virtuels. De plus, les données sont en cours d'écriture correctement sur la base de données. Il apparaît donc que le setter fonctionne correctement. Le getter utilise la même technique illustrée dans les rails.
Dès que je reviens sur mon PC, je posterai le code d'attribut Getter et Setter.
Dans mon fichier Environnement.rb, j'ai en plus de l'entrée du fuseau horaire: Time :: DATE_FORMATS [: Event_Date] = "% B% D,% Y% I:% M% P" Voici l'attribut virtuel Getter et Setter CODE: DEF Formatted_EventDate si Self.EventDate! = nil self.eventdate.to_s (: event_date) End Fin (: Event_Date) End Find Formatted_eventdate = (valeur) Self.eventdate = TIME.PARSE (VALEUR) Finissez-la comme si la date de date de la valeur DateTime est être complètement ignoré.
Je pense que le problème est isolé aux rails en lisant les données de la base de données. Les écritures à la DB semblent bien. Pour tester, j'ai ce code getter: def formatéded_eventdate si Self.EventDate! = NIL TIME.PARSE ("2009-12-30 22:00:00"). TO_S (: Event_Date) # Self.eventdate.Te_s (: Event_Date ) Terminez avec ce code, la date s'affiche correctement comme le: 30 décembre 2009 à 10h00 10:00 Toutefois, lorsque je commente ce code en faveur de la lecture de la valeur EventDate extrait dans la base de données, qui est stockée comme: 2009-12-30 22:00:00 La date est maintenant affichée comme suit: 01 janvier 2000 à 22h00