Time.dst? is broken in Rails 6.0.3.4

[alextaujenis]

Steps to reproduce

It looks like the .dst? flag on Time and DateTime objects stopped working. I'm just following the docs and I can't get the same console output:
https://api.rubyonrails.org/v6.0.3.4/classes/ActiveSupport/TimeWithZone.html#method-i-dst-3F

Expected behavior

Time.zone = 'Eastern Time (US & Canada)'    # => 'Eastern Time (US & Canada)'
Time.zone.parse("2012-5-30").dst?           # => true
Time.zone.parse("2012-11-30").dst?          # => false

Actual behavior

Time.zone = 'Eastern Time (US & Canada)'    # => 'Eastern Time (US & Canada)'
Time.zone.parse("2012-5-30").dst?           # => true
Time.zone.parse("2012-11-30").dst?          # => true

These dates are spread across daylight savings time changes, so they should return a different answer, but I received true both times, which is incorrect.

System configuration

Rails v6.0.3.4
Ruby v2.7.2

[rafaelfranca]

>> Time.zone = 'Eastern Time (US & Canada)'
>> Time.zone.parse("2012-5-30").dst?
=> true
>> Time.zone.parse("2012-11-30").dst?
=> false
>> Rails.version
=> "6.0.3.4"

The return of those methods depends on the tzinfo database of your OS or in the tzinfo-data gem. Check you have a up-to-date version of the timezone database.

[alextaujenis]

• I was running apk add tzdata in Alpine linux
• Adding gem 'tzinfo-data' to my Gemfile fixed this issue

Thank you @rafaelfranca!

[Boztown]

This one took us by surprise. The tzinfo database changed its default database format to "slim" in 2020b. In one environment we were locked to 2020a, which was fine, but in another instance we had allowed Alpine to use the latest. The silent lack of DST support ended up creating a bunch of incorrect UTC conversions in the database. Our solution is to ensure we're using the tzinfo-data gem now and forego relying on the OS package. Lesson learned. We had every dependency locked down, except that one...

Posting this for anyone else who may have been hit by this.

EDIT: Unfortunately our test suite was running in an image still using 2020a, otherwise our tests would have caught it. Again, lesson learned.

[aardvarkk]

I wanted to note for future visitors to this issue, the problem is not a lack of up-to-date tzdata. In fact, the problem starts occurring if your version of tzdata is too new (2020b or newer, with 2020b being having been released on Oct 6, 2020). The reason Alpine triggers this bug is because it seems they're more aggressive with package updating, so they're already on 2020c (from Oct 16, 2020), as opposed to something like Heroku's heroku-18 image that's still running 2020a.

There's more detail in the TZInfo gem thread here: tzinfo/tzinfo#120

This seems like it might become problem for a lot more people as we move past this DST switch and as other common Docker images start pulling in more recent tzdata versions. I just took the new heroku-20 beta image for a spin, and it still uses 2020a, so a default Rails install on Heroku should be safe for a while.