如何为Rails 7的ActiveRecord查询设置时区以获取准确统计数据？

问题背景 #

开发面向德国用户的Rails 7应用，本地及生产服务器（Ubuntu）系统时间均为德国时间（Fri Jun 21 12:10:23 CEST 2024），但PostgreSQL数据库以UTC时区存储时间数据。CRON任务于德国时间午夜（对应UTC时间22:00）启动，基于数据生成的统计结果不准确。尝试设置config.time_zone = 'Berlin'无效，需添加config.active_record.default_timezone = :local才可能生效，但担心该配置对现有数据的影响及后续风险。

统计异常原因分析 #

结合你提供的统计SQL与数据库数据，问题出在原生SQL未按德国时区处理时间：
你的统计SQL直接使用DATE_TRUNC('day', created_at)，该函数基于数据库默认时区（UTC）对时间进行按天截断。例如：

• 数据库记录#2（2024-06-20 22:00:04.305209 UTC）对应德国时间为2024-06-21 00:00:04 CEST，但按UTC截断会被归到2024-06-20的分组中；
• CRON任务在德国午夜启动，统计的是德国时间的前一天数据，因此你预期记录#2、#3、#4都应被统计，但实际只有记录#4（UTC2024-06-21 00:00:21，对应德国时间2024-06-21 02:00:21）被归到UTC2024-06-21分组，才会被选中。

配置修改的影响与风险 #

现有数据的变化 #

修改config.active_record.default_timezone = :local后，数据库中已存储的UTC数据不会发生任何存储层面的变更。该配置仅影响Rails应用对时间的读写逻辑：

• 写入数据：Rails会将德国时区（config.time_zone = 'Berlin'）的时间转换为UTC后存入数据库；
• 读取数据：Rails会将数据库中的UTC时间转换为德国时区的时间对象返回给应用。

潜在风险场景 #

1. 原生SQL适配问题：所有直接操作数据库时间字段的原生SQL（如你的统计语句），若未添加时区转换逻辑，仍会基于UTC计算，导致结果与Rails应用层面的时间处理不一致。
2. 数据库字段类型风险：若你的时间字段类型为timestamp without time zone（而非timestamptz），设置:local后，Rails会直接将德国时区的时间写入数据库（不带时区标记），而原有数据是UTC格式，读取时会被错误解析为UTC时间，导致数据完全混乱。
3. 业务逻辑兼容性：若代码中存在依赖UTC时间的逻辑（如第三方API交互、特定定时任务逻辑），未做适配会出现时间偏差错误。
4. 定时任务触发逻辑：需确保CRON任务或Rails内部定时任务（如Sidekiq）的时区配置与应用时区一致，避免触发时间不符合预期。

安全解决方案 #

方案1：不修改default_timezone，修复统计SQL #

无需调整Rails核心时区配置，仅修改统计SQL，在数据库层面按德国时区截断时间：

SELECT DATE_TRUNC('day', created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Europe/Berlin') AS day, 
       COUNT(id) as tasks, 
       SUM(revenue) AS revenue, 
       SUM(tasks_created) AS tasks_created
FROM tasks 
GROUP BY day
ORDER BY day DESC
LIMIT 10

• 逻辑说明：created_at AT TIME ZONE 'UTC'将带时区的时间转换为UTC时间戳，再通过AT TIME ZONE 'Europe/Berlin'转换为德国时区时间，最后按德国时间的天分组。

方案2：修改Rails时区配置（需谨慎） #

若需统一应用层面的时区处理，按以下步骤操作：

1. 确认数据库字段类型：确保时间字段为timestamptz（带时区）。若为timestamp，需先转换字段类型：

   ALTER TABLE tasks ALTER COLUMN created_at TYPE timestamptz USING created_at AT TIME ZONE 'UTC';
   

2. 配置Rails时区：

   # config/application.rb
   config.time_zone = 'Berlin'
   config.active_record.default_timezone = :local
   

3. 适配所有原生SQL：所有直接操作时间的SQL都需添加时区转换逻辑，确保与Rails处理一致。
4. 全面测试：覆盖定时任务、第三方集成、业务逻辑等所有场景，验证时间处理是否正确。

内容的提问来源于stack exchange，提问作者user984621