Gwoli wprowadzenia:
t = Time.now; Order.create(:created_at => t); Order.find(:first, :conditions => {:created_at => t})
zwraca nil
(przykładowo dla naszej strefy czasowej, find szuka (wg. czasu lokalnego) wpisu o 2 godziny późniejszego względem dodanego rekordu - który został zapisany w UTC)
Żeby powyższe działało jak powinno, musi być:
t = Time.zone.now (albo Time.now.getutc)
Pociąga to za sobą również problem z Date.today (albo Time.now.to_date)
Ponieważ Date.today nie przechowuje informacji o strefie czasowej, to wykonując
Order.find(:all, :conditions => {:some_date_field => Date.today})
uzyskamy inne wpisy przed i inne po godzinie 2:00 AM (przyjmując znowu naszą strefę czasową)
To skolei można skorygować pisząc
Time.now.getutc.to_date
Przechodząc do zasadniczego pytania:
Czy jeśli stosuje się lokalizację, to Time.now.getutc i Time.now.getutc.to_date to jedyne sposoby radzenia sobie z zapytaniami zawierającymi datę?
Też kiedyś miałem z tym problem. A właście kolega, z poprzedniej firmy…
Nie mniej jednak wyszło na to, że w takich wypadkach najlepiej trzymać się UTC gdzie się da, a lokalizacją czasu najlepiej zająć się w widokokach / helperach/configu railsów. Nie pamiętam tylko co to za baza była (ale najprawdopodobniej postgre). A i coś mi tak świta, że wypadało korzystać z DateTime.now
ale nie wierz mi na słowo, sprawdź i pochwal się do czego doszedłeś
Po czyms takim wszystko powinno byc konwertowane w locie. Jesli dane ida do bazy zamieniane sa na utc, jesli ida z bazy zamieniane sa na Time.zone_default
Time.zone.now
=> Tue, 23 Jun 2009 17:41:18 CEST +02:00
Time.now
=> Tue Jun 23 08:41:37 -0700 2009[/code]
Oczywiście Time.now pokazuje aktualną datę na serwerze, a Time.zone.now aktualną datę w strefie czasowej, która została wcześniej ustawiona w config/environment.rb:
[code Ruby] # Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.
Run “rake -D time” for a list of tasks for finding time zone names.
