Time.current.utc_offset and Time.zone.utc_offset are different during DST

Verified that it's only a problem in DST.

  john-mbp:rails john$ ruby script/console 
  Loading development environment (Rails 3.0.pre)
  /Users/john/projects/rails/rails/config/environment.rb:11: warning: already initialized constant Application
  >> Time.zone = "Eastern Time (US & Canada)"
  => "Eastern Time (US & Canada)"
  >> Time.now
  => Sat Sep 26 11:19:42 -0400 2009
  >> Time.zone.utc_offset
  => -18000
  >> Time.current.utc_offset
  => -14400
  >> require 'timecop'
  => []
  >> Timecop.travel(2009, 12, 12)
  => Sat Dec 12 00:00:00 -0500 2009
  >> Time.zone.utc_offset
  => -18000
  >> Time.current.utc_offset
  => -18000

Using Timecop to move ahead to Dec, these two methods do in fact return the same value. It would appear that Vladimir's assertion that they should both return 14400 during DST is correct.

Now that I think about this further, I'm not sure that a change is warranted. A TimeZone object exists outside of the context of an actual Time instance. It's somewhat arbitrary to return its utc_offset based on Time.now. In essence, I don't think a TimeZone should consult "now" when asked for its offset. A TimeWithZone object carries with it a specific Time instance, and so it makes sense for it to take DST into account.

-1 on changing this.

+1 verified

Given I don't misunderstand I'll have to disagree with John. I took a look at the docs for Time.current() ...

Returns Time.zone.now when config.time_zone is set, otherwise just returns Time.now.

and Time.zone() ...

Returns the TimeZone for the current request, if this has been set (via Time.zone=).

... and concluded that since Time.current() depends on Time.zone() they should have the same utc_offset. Please do correct me if I'm wrong, though.

My point is that a TimeZone object exists in the absence of a specific time. It's a matter of responsibility. A TimeZone should only take DST into account if it's asked for its utc_offset in the context of a specific Time. Since this is not the case when calling Time.zone, it shouldn't just arbitrarily choose to consult Time.now to determine whether or not to include DST in its calculation.

At no point does a call to Time.zone.utc_offset indicate the exact Time against which you want the utc_offset to be evaluated. If we instead had a function like Time.zone.utc_offset_for_time(a_time), then I'd say yes, we should be including DST in the offset.

Anyone else feel strongly about this?