Блог

Главная - Вопросы по программированию - Rails не переходит с перехода на летнее время

Rails не переходит с перехода на летнее время

#ruby-on-rails #ruby #timezone

#ruby-on-rails #ruby #Часовой пояс

Вопрос:

Rails версия: 6.0.3.4
Версия Ruby: 2.6.6
tzinfo gem версия: 1.2.7

Хотя переключение на дневное время должно было завершиться 1 ноября, мое приложение rails каким-то образом все еще использует PDT ( -7:00 ), хотя я ожидаю, что оно будет в PST ( -08:00 ) 4 ноября.

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

Вот что я знаю до сих пор:

  • Для ОС /etc/localtime установлено правильное значение GMT
  • config.time_zone имеет значение Pacific Time (US amp; Canada)
  • config.active_record.default_timezone не установлено
  • Для Postgres установлено значение UTC

Кто-нибудь знает, что происходит? Я заметил, что Time.zone.tzinfo.current_period это немного странно (установлено на 2007), но не уверен, актуально ли это:

 > 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

Обновление: вот информация о zdump, так что, похоже, ОС имеет правильную информацию:

 > 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

Еще TZInfo :

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

Комментарии:

1. Да, этот current_period неверен. local_start должно быть 1 ноября 2020 года, а local_end должно быть 14 марта 2021 года.

2. 11 марта 2007 года совпадает с последним национальным переходом на летнее время в США.

3. Полезно знать! Просто добавлены данные zdump к вопросу

4. Что TZInfo::DataSource.get говорит? См. TZInfo — Источники данных .

5. Просто обновил q, чтобы включить его!

Ответ №1:

Это произошло из-за несовместимости tzinfo gem с новой версией tz: https://github.com/tzinfo/tzinfo/issues/120

Версия 2020b компилятора часовых поясов «zic» была изменена на вывод файлов zoneinfo с использованием нового формата «slim» по умолчанию. Формат slim требует, чтобы пользователи файлов zoneinfo интерпретировали правила, а не просто читали список переходов.

В настоящее время TZInfo поддерживает только чтение переходов и потребует внесения изменений для использования правил. Следовательно, это приведет к неправильному смещению в какой-то момент после окончательного перехода в файле.

Проблема начинается с 2020b формата. ruby:2.6-alpine устанавливается 2020c по умолчанию при запуске apk add tzdata 

 
> docker run -it alpine:3.12
/ > apk add tzdata amp;amp; 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)