2010-10-23 21 views
3
> e = Event.first 
> e.registration_start_utc #registration_start_utc is a datetime column 
=> Sat, 23 Oct 2010 06:38:00 UTC +00:00 
> e.registration_start_utc.utc? 
=> true 
> ActiveSupport::TimeZone.find_tzinfo("America/New_York").utc_to_local(e.registration_start_utc) 
=> Sat, 23 Oct 2010 02:38:00 UTC +00:00 

2 questions à ce sujet:rails de temps économies utc_to_local et la lumière du jour

1) Pourquoi cette dernière sortie montrant "UTC" - l'heure se convertit (6 => 2), mais il est dit encore UTC . Pourquoi pas EST/EDT?

2) Que se passe-t-il lorsque l'heure d'été passe et que le décalage pour New York passe de -4 à -5? La valeur dans la base de données ne change pas alors ma seule conclusion est que mon application commencera à montrer "1:38" partout au lieu de la bonne 2:38?

Je suis surtout préoccupé par # 2 ici. # 1 est plus d'une curiosité.

Merci!

+0

Voir [ici] (http://rubyforge.org/pipermail/tzinfo -users/2007-September/000015.html) pour raisonner par Phil – Zabba

Répondre

1

2) utc_to_local utilise la date pour déterminer quel décalage est correct, de sorte que la sortie sera toujours la même pour une date donnée.

Vous pouvez tester pour cela comme ceci:

t = Time.utc(2011,3, 14, 12) 
# => 2011-03-14 12:00:00 UTC 
t2 = Time.utc(2011,3, 11, 12) 
# => 2011-03-11 12:00:00 UTC 
ActiveSupport::TimeZone.find_tzinfo("America/New_York").utc_to_local(t) 
# => 2011-03-14 08:00:00 UTC 
ActiveSupport::TimeZone.find_tzinfo("America/New_York").utc_to_local(t2) 
# => 2011-03-14 07:00:00 UTC 

1) Il ne semble pas juste moi non plus. Ma conjecture est qu'ils ne s'intéressent qu'à la valeur réelle de l'heure, des minutes, etc ... et ne tiennent pas compte du fuseau horaire.

Dans tous les cas, vous pourriez être mieux d'utiliser:

e.registration_start_utc.in_time_zone("Eastern Time (US & Canada)") 

Voir aussi this question Je viens de demander ...