Reputation: 361
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:
/etc/localtime
is set to correct GMTconfig.time_zone
is set to Pacific Time (US & Canada)
config.active_record.default_timezone
isn't setAnyone 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
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