是的,它看起来像一个错误。然而,它不是 Rails,而是 Ruby Time类。它在 2038 年之后的时代存在问题。
例如,对于 Ruby 1.8.7:
> Time.local(2037,8,16,9,30,15)
=> Sun Aug 16 09:30:15 -0400 2037
>
> Time.local(2038,8,16,9,30,15)
=> Mon Aug 16 09:30:15 -0500 2038
JRuby 1.6.7.2 - 例如 - 没有这个问题:
> Time.local(2038,8,16,9,30,15)
=> Mon Aug 16 09:30:15 -0400 2038
请注意,在 64 位系统上的 MRI Ruby 上,支持添加持续时间的 ActiveSupport 时间扩展最终通过 active_support/core_ext/time/calculations.rb 中的此方法调用 Time.local 或 Time.utc:
# Returns a new Time if requested year can be accommodated by Ruby's Time class
# (i.e., if year is within either 1970..2038 or 1902..2038, depending on system architecture);
# otherwise returns a DateTime
def time_with_datetime_fallback(utc_or_local, year, month=1, day=1, hour=0, min=0, sec=0, usec=0)
::Time.send(utc_or_local, year, month, day, hour, min, sec, usec)
rescue
offset = utc_or_local.to_sym == :local ? ::DateTime.local_offset : 0
::DateTime.civil(year, month, day, hour, min, sec, offset)
end
我想问题是多年来> = 2038,他们期待一个溢出异常并使用 DateTime 代替。在 64 位系统上,这不会发生。
更新:此分析对于 Ruby 1.9.2+ 是不正确的。Time.local 按预期工作,但仍然出现原始问题。