Atsushi
Atsushi

Reputation: 361

Rails does not transition out from daylight savings time

Rails ver: 6.0.3.4
Ruby ver: 2.6.6
tzinfo gem ver: 1.2.7

Although daylight switching was supposed to end on Nov 1st, my rails application is somehow still using PDT (-7:00) when I expect it to be in PST (-08:00) on Nov 4th.

> Time.now
2020-11-05 02:45:15 +0000
> Time.zone.now
Wed, 04 Nov 2020 19:45:23 PDT -07:00

Here's what I know so far:

Anyone know what's going on? I noticed that Time.zone.tzinfo.current_period is a little odd (set to 2007) but not sure if it's relevant:

> Time.zone.tzinfo.current_period
#<TZInfo::TimezonePeriod: #<TZInfo::TimezoneTransitionDefinition: #<TZInfo::TimeOrDateTime: 1173607200>,#<TZInfo::TimezoneOffset: -28800,3600,PDT>>,nil>
> Time.zone.tzinfo.current_period.local_start
Sun, 11 Mar 2007 03:00:00 +0000
> Time.zone.tzinfo.current_period.local_end
nil

Update: Here are the zdump info, so looks like OS has the right info:

> zdump -v /usr/share/zoneinfo/America/Los_Angeles | grep 2020
/usr/share/zoneinfo/America/Los_Angeles  Sun Mar  8 09:59:59 2020 UT = Sun Mar  8 01:59:59 2020 PST isdst=0 gmtoff=-28800
/usr/share/zoneinfo/America/Los_Angeles  Sun Mar  8 10:00:00 2020 UT = Sun Mar  8 03:00:00 2020 PDT isdst=1 gmtoff=-25200
/usr/share/zoneinfo/America/Los_Angeles  Sun Nov  1 08:59:59 2020 UT = Sun Nov  1 01:59:59 2020 PDT isdst=1 gmtoff=-25200
/usr/share/zoneinfo/America/Los_Angeles  Sun Nov  1 09:00:00 2020 UT = Sun Nov  1 01:00:00 2020 PST isdst=0 gmtoff=-28800

More TZInfo:

> TZInfo::DataSource.get
#<TZInfo::ZoneinfoDataSource: /usr/share/zoneinfo>

Upvotes: 4

Views: 300

Answers (1)

Atsushi
Atsushi

Reputation: 361

This was due to tzinfo gem's incompatibility with the new tz version: https://github.com/tzinfo/tzinfo/issues/120

The 2020b version of the 'zic' time zone compiler has changed to output zoneinfo files using a new 'slim' format by default. The slim format requires users of the zoneinfo files to interpret rules instead of just reading a list of transitions.

TZInfo currently only supports reading the transitions and will require modification to use the rules. Consequently, it'll produce the wrong offset at some point after the final transition in the file.

The issue starts from the 2020b format. ruby:2.6-alpine installs 2020c by default when you run apk add tzdata


> docker run -it alpine:3.12
/ > apk add tzdata && apk list | grep tzdata
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/1) Installing tzdata (2020c-r0)
Executing busybox-1.31.1-r19.trigger
OK: 9 MiB in 15 packages
tzdata-2020c-r0 x86_64 {tzdata} (Public-Domain) [installed]
tzdata-doc-2020c-r0 x86_64 {tzdata} (Public-Domain)

Upvotes: 3

Related Questions