Mam kwerendę opartą na czasie na szynach, która ma jakieś dziwne zachowanie wrażliwe na strefę czasową, chociaż wiem, że używam UTC. W skrócie, te zapytania dają różne odpowiedzi:

>> Model.find(:all,:conditions=>['created_at<=?',(Time.now-1.hours).gmtime]).length
=> 279
>> Model.find(:all,:conditions=>['created_at<=?',(Time.now-1.hours)]).length
=> 280

Tam, gdzie DB rzeczywiście zawiera jeden model utworzony w ciągu ostatniej godziny, a całkowita liczba modeli wynosi 280. Zatem tylko pierwsze zapytanie jest poprawne.

Jednak w środowisku.rb mam:

config.time_zone = 'UTC'

Systemowa strefa czasowa (podana jako „data”) to BST (czyli GMT + 1) - więc jakoś to staje się traktowane jako UTC i łamanie zapytań.

Powoduje to różnego rodzaju problemy, ponieważ muszę sparametryzować zapytanie przechodzące w różne czasy do akcji (które są następnie konwertowane przy użyciu Time.parse ()), i nawet jeśli wysyłam w czasie UTC, to wyłącza się o godzinę „DST często wydaje plony. Nawet użycie '.gmtime ()' nie zawsze wydaje się to naprawiać.

Oczywiście różnica jest spowodowana w jakiś sposób przez niejawną konwersję, która powoduje, że BST jest niepoprawnie traktowany jako UTC, ale dlaczego? Czy szyny nie przechowują znaczników czasu w UTC? Czy strefa czasowa klasy Time nie jest znana? Używam Railsów 2.2.2

Co się tu dzieje - i jaki jest bezpieczny sposób na programowanie?

edytuj, dodatkowe informacje, aby pokazać, co robią klasa DB i czas:

>> Model.find(:last).created_at
=> Tue, 11 Aug 2009 20:31:07 UTC +00:00
>> Time.now
=> Tue Aug 11 22:00:18 +0100 2009
>> Time.now.gmtime
=> Tue Aug 11 21:00:22 UTC 2009