有谁知道如何在rails 2.3中适当处理用户时区?

时间:2010-12-25 05:26:06

标签: ruby-on-rails ruby timezone

我们正在构建一个需要在多个时区显示日期(更重要的是计算它们)的rails应用程序。

有人能指出我如何使用rails 2.3(.5或.8)中的用户时区吗?

我见过的最具包容性的文章详细介绍了用户时区应该如何工作:http://wiki.rubyonrails.org/howtos/time-zones ...虽然不清楚这是什么时候编写的,或者是什么版本的rails。具体而言,它表明:

“Time.zone - 实际用于显示目的的时区。可以手动设置,以基于每个请求覆盖config.time_zone。”

将条款定义为“显示目的”和“按请求基础”。

在我的机器上,这是真的。但是在生产中,两者都不是真的。设置Time.zone会持续超过请求的结束(对所有后续请求),并且还会影响AR保存到数据库的方式(基本上将任何日期视为已经在UTC中,即使它不存在),从而节省了完全不合适的值

我们与乘客一起在生产中运行Ruby Enterprise Edition。如果这是我的问题,我们是否需要切换到JRuby或其他东西?

为了说明问题,我现在在ApplicationController中添加了以下操作:

def test
p_time = Time.now.utc
s_time = Time.utc(p_time.year, p_time.month, p_time.day, p_time.hour)

logger.error "TIME.ZONE" + Time.zone.inspect
logger.error ENV['TZ'].inspect
logger.error p_time.inspect
logger.error s_time.inspect

jl = JunkLead.create!
jl.date_at = s_time

logger.error s_time.inspect
logger.error jl.date_at.inspect

jl.save!

logger.error s_time.inspect
logger.error jl.date_at.inspect


render :nothing => true, :status => 200
end


def test2
Time.zone = 'Mountain Time (US & Canada)'
logger.error "TIME.ZONE" + Time.zone.inspect
logger.error ENV['TZ'].inspect

render :nothing => true, :status => 200
end


def test3
Time.zone = 'UTC'
logger.error "TIME.ZONE" + Time.zone.inspect
logger.error ENV['TZ'].inspect


render :nothing => true, :status => 200
end

他们产生以下结果:

Processing ApplicationController#test (for 98.202.196.203 at 2010-12-24 22:15:50) [GET]
TIME.ZONE#<ActiveSupport::TimeZone:0x2c57a68 @tzinfo=#<TZInfo::DataTimezone: Etc/UTC>, @name="UTC", @utc_offset=0>
nil
Fri Dec 24 22:15:50 UTC 2010
Fri Dec 24 22:00:00 UTC 2010
Fri Dec 24 22:00:00 UTC 2010
Fri, 24 Dec 2010 22:00:00 UTC +00:00
Fri Dec 24 22:00:00 UTC 2010
Fri, 24 Dec 2010 22:00:00 UTC +00:00
Completed in 21ms (View: 0, DB: 4) | 200 OK [http://www.dealsthatmatter.com/test]


Processing ApplicationController#test2 (for 98.202.196.203 at 2010-12-24 22:15:53) [GET]
TIME.ZONE#<ActiveSupport::TimeZone:0x2c580a8 @tzinfo=#<TZInfo::DataTimezone: America/Denver>, @name="Mountain Time (US & Canada)", @utc_offset=-25200>
nil
Completed in 143ms (View: 1, DB: 3) | 200 OK [http://www.dealsthatmatter.com/test2]


Processing ApplicationController#test (for 98.202.196.203 at 2010-12-24 22:15:59) [GET]
TIME.ZONE#<ActiveSupport::TimeZone:0x2c580a8 @tzinfo=#<TZInfo::DataTimezone: America/Denver>, @name="Mountain Time (US & Canada)", @utc_offset=-25200>
nil
Fri Dec 24 22:15:59 UTC 2010
Fri Dec 24 22:00:00 UTC 2010
Fri Dec 24 22:00:00 UTC 2010
Fri, 24 Dec 2010 15:00:00 MST -07:00
Fri Dec 24 22:00:00 UTC 2010
Fri, 24 Dec 2010 15:00:00 MST -07:00
Completed in 20ms (View: 0, DB: 4) | 200 OK [http://www.dealsthatmatter.com/test]

Processing ApplicationController#test3 (for 98.202.196.203 at 2010-12-24 22:16:03) [GET]
TIME.ZONE#<ActiveSupport::TimeZone:0x2c57a68 @tzinfo=#<TZInfo::DataTimezone: Etc/UTC>, @name="UTC", @utc_offset=0>
nil
Completed in 17ms (View: 0, DB: 2) | 200 OK [http://www.dealsthatmatter.com/test3]

Processing ApplicationController#test (for 98.202.196.203 at 2010-12-24 22:16:04) [GET]
TIME.ZONE#<ActiveSupport::TimeZone:0x2c57a68 @tzinfo=#<TZInfo::DataTimezone: Etc/UTC>, @name="UTC", @utc_offset=0>
nil
Fri Dec 24 22:16:05 UTC 2010
Fri Dec 24 22:00:00 UTC 2010
Fri Dec 24 22:00:00 UTC 2010
Fri, 24 Dec 2010 22:00:00 UTC +00:00
Fri Dec 24 22:00:00 UTC 2010
Fri, 24 Dec 2010 22:00:00 UTC +00:00
Completed in 151ms (View: 0, DB: 4) | 200 OK [http://www.dealsthatmatter.com/test]

上面应该清楚,对/ test的第二次调用显示Time.zone设置为Mountain,即使它不应该。

此外,检查数据库显示,在test2之后运行的测试操作保存了一个日期为2010-12-22 15:00:00的JunkLead记录,这显然是错误的。

3 个答案:

答案 0 :(得分:9)

经过详尽的研究后,现在完全清楚的是,在大多数版本的Rails(包括2.3和3)中,Time.zone都被破坏了。此功能使用中心线程哈希来存储设置的值(应该是线程安全的,而不是),并最终修改所有后续请求的行为。此外,与文档相反,设置Time.zone会修改ActiveRecord行为并将日期时间保存在新区域中,而不是在config中指定的日期时间(通常为UTC)。

在Rails修复之前,我们选择手动使用Timezones,可以通过未记录的默认方法访问:

ActiveSupport::TimeZone['Arizona'].now (or .local, or .parse).

此外,我修补了Time和ActiveSupport :: TimeWithZone,以便将时间片段轻松转换为其他区域。要清楚,我指的是不同区域的相应时刻,而不是同时时刻。

>> Time.utc(2011)
=> Sat Jan 01 00:00:00 UTC 2011
>> Time.utc(2011).in_time_zone('Arizona')
=> Fri, 31 Dec 2010 17:00:00 MST -07:00 #Simultaneous
>> Time.utc(2011).change_zone('Arizona')
=> Sat, 01 Jan 2011 00:00:00 MST -07:00 #Corresponding

补丁如下:

module ActiveSupport #:nodoc:
  module CoreExtensions #:nodoc:
    module Time #:nodoc:
      module ZoneCalculations
        def self.included(base) #:nodoc:
          base.class_eval do
            alias_method_chain :change, :zone
          end
        end

        def change_zone(new_zone)
          new_zone = ::Time.__send__(:get_zone, new_zone)
          return self if new_zone.name == zone
          new_zone.local(year,month,day,hour,min,sec,usec)
        end

        def change_with_zone(options)
          result = change_without_zone(options)
          options[:zone] ? result.change_zone(options[:zone]) : result
        end

      end
    end
  end
  class TimeWithZone
    def change_zone(new_zone)
      time.change_zone(new_zone)
    end
    def change(options)
      time.change(options)
    end
  end

end

class Time
  include ActiveSupport::CoreExtensions::Time::ZoneCalculations
end

答案 1 :(得分:8)

你是正确的,因为Rails不会自动重置每个请求的时区。维基作者给出了一个示例,其中时区在前置过滤器中设置,因此他从未遇到时区在请求之间“泄漏”的问题(因为在请求之前正确设置了时区)。 TimeZone.zone=的RDoc文档中使用的示例类似。所以我认为这是一个文档问题。

更改时区不是本地请求,而是本地线程。 Rails将所选时区存储在当前线程中(请参阅Thread.current.[:time_zone]),而不是当前请求中。由于同一个线程处理多个请求,因此对Time.zone的更改在请求之间是持久的。

我认为在您的方案中使用时区的正确方法是使用Time.use_zone

def my_action
  Time.zone # 'UTC'
  Time.use_zone('Mountain Time (US & Canada)') do
    Time.zone # 'Mountain Time (US & Canada)'
  end
  Time.zone # 'UTC'
end

我没有时间查看您的ActiveRecord问题。我完成后会返回更新。

答案 2 :(得分:0)

我在构建支持票务系统时遇到了这个问题。我的解决方案如下。

将Datetime SQL和ActiveRecord时区设置为UTC。

在应用的配置中设置所需的时间格式。

制作一个CSS类,了解您希望日期的CSS看起来如何。将名称命名为Unique。例如。 UTCDate

编写javascript以在页面中搜索指定的Date DOM类(上面的UTCDate)。由于Javascript由最终用户执行,因此它将使用本地计算机设置的值替换该值。如果您遇到解析错误,请将时间保留为UTC。看here for relevant javascript

此解决方案的优点是您的应用程序没有像许多论坛那样的愚蠢时区选择器。它还可以减少服务器负载和代码库大小(因为您不必存储或处理有关客户端时区的任何信息)来处理重要但困难的任务。