2013-02-25 2 views
0

Je suis au Brésil, qui est -3 heures de l'UTC. Je n'ai pas fait de configuration pour les fuseaux horaires dans Rails, et ma console se comporte bizarre, voici l'exemple:bizarre comportement de fuseau horaire ActiveRecord dans Rails

1.9.3p194 :099 > FreeTime.first.starts_at 
    => 2000-01-01 11:15:26 UTC 
    1.9.3p194 :100 > FreeTime.first.starts_at.localtime 
    => 2000-01-01 09:15:26 -0200 
    1.9.3p194 :101 > FreeTime.first.starts_at.localtime.zone 
    => "BRST" 
    1.9.3p194 :102 > Time.now 
    => 2013-02-25 10:24:51 -0300 
    1.9.3p194 :103 > Time.now.zone 
    => "BRT" 
    1.9.3p194 :104 > Time.zone 
    => (GMT+00:00) UTC 

Comme vous pouvez le voir, le problème est que Rails temps classe chiffres correctement mon localzone (de mon horloge système), mais ActiveRecord se trompe d'une manière ou d'une autre. Je voudrais savoir pourquoi ActiveRecord découvre à tort que mon fuseau horaire est BRST (le droit est BRT), même si je n'ai pas fait de configuration.

Répondre

2

Ça ne se trompe pas du tout. Il se rend compte que vous êtes dans le fuseau horaire du Brésil, et au 2000-01-01 11:15:26 UTC, le fuseau horaire du Brésil était dans BRST, qui est UTC-2.

En the year 2000, la transition BRST -> BRT était le 26 février.

Vous devez comprendre que votre fuseau horaire n'est pas vraiment "BRT" ou "BRST" - c'est une combinaison des deux, y compris les transitions entre eux. Donc, par exemple, je suis au Royaume-Uni. Nous sommes actuellement sur GMT, nous allons passer à BST en été - donc la sortie correcte pour une valeur de temps en été serait BST, à UTC + 1.

+0

Bonne réponse! Je commence à réaliser que la meilleure façon d'avoir un champ Time sur la base de données est d'avoir et Integer pour Hour, et un Integer pour Minutes. Comme je suis au Brésil, chaque fois que je stocke un Time, ce sera en 2000-01-01, et par conséquent dans le mauvais fuseau horaire. – alexandrecosta

+0

@ user1261084: C'est rarement la meilleure façon de commencer les heures, pour être honnête. Dans * la plupart * des cas, le stockage des valeurs UTC est l'approche d'écriture - mieux il y a des cas où le stockage de la date/heure locale avec le fuseau horaire est meilleur. –

+0

Si j'ai un rendez-vous tous les mardis à 15h00, l'heure d'été continuera à 15h00. Mais si je le stocke sur la base de données comme "15:00:00 -0300", en été, il me rendra que le rendez-vous est sur "16:00:00 -0200". Très confus ... L'heure est l'heure, pour beaucoup de cas, elle ne dépend pas des zones. DateTime repose sur des zones. Je ne comprends pas pourquoi Rails insiste pour enregistrer la date dans les attributs de la base de données Time. Il devrait exister une meilleure approche pour éviter cette confusion. En ce moment je stocke le temps comme "11:00:00 -0300", et il me renvoie "11:00:00 -0200": https://gist.github.com/anonymous/5030404 – alexandrecosta