Я в Бразилии, что составляет -3 часа с UTC. Я не сделал никакой конфигурации для часовых поясов в Rails, и моя консоль ведет себя странно, вот пример:странное поведение часового пояса ActiveRecord в 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
Как вы можете видеть, проблема в том, что класс Rails Time выяснит правильно мой localzone (от системных часов), но ActiveRecord почему-то ошибается. Я хотел бы знать, почему ActiveRecord ошибочно определяет, что мой часовой пояс - BRST (справа - BRT), хотя я и не сделал никакой конфигурации.
Отличный ответ! Я начинаю понимать, что лучший способ иметь поле «Время» в базе данных - иметь и Integer для Hour и Integer для минут. Поскольку я в Бразилии, каждый раз, когда я храню время, он будет в 2000-01-01 и, следовательно, в неправильный часовой пояс. – alexandrecosta
@ user1261084: Это редко лучший способ начать время, честно говоря. В * большинстве * случаях сохранение значений в формате UTC является методом записи - лучше всего есть случаи, когда лучше хранить локальную дату/время вместе с часовым поясом. –
Если у меня назначена встреча каждый вторник в 15:00, в летнее время она будет продолжаться в 15:00. Но если я сохраню его в базе данных как «15:00:00 -0300», в летнее время он вернет мне, что назначение на «16:00:00 -0200». Очень запутанно ... Время пришло, потому что во многих случаях он не полагается на Зоны. DateTime полагается на зоны. Я не понимаю, почему Rails настаивает на записи даты в атрибутах базы данных Time. Он должен существовать лучше, чтобы избежать этой путаницы. Сейчас я храню Time как «11:00:00 -0300», и он возвращает мне «11:00:00 -0200»: https://gist.github.com/anonymous/5030404 – alexandrecosta