首先得明确：Heroku提到的「修改数据库默认时区是不良实践」，是针对多时区、多租户或面向全球用户的应用场景，而你的情况是「仅服务特定国家，无跨时区需求」，这个前提完全不同——在你的场景下，执行ALTER database my_db SET timezone ='Europe/Brussels'不仅不是不良实践，反而是最合理、最省力的迁移适配方案。

我来拆解下原因和注意事项：

为什么Heroku会这么说？ #

Heroku的建议核心是避免强制数据库时区导致的全局混乱：如果你的应用需要服务不同时区的用户，或者数据需要在不同时区环境下流转，固定数据库时区会让timestamp without timezone字段的语义变得模糊——毕竟这类字段不存储时区信息，一旦数据库时区变化，读取到的时间就会出现偏移。但你的应用没有这些场景，所以这个限制对你不适用。

你的场景下这么做的核心优势 #

• 对齐旧系统行为：旧服务器用Europe/Brussels时区，所有NOW()/CURRENT_TIME生成的都是布鲁塞尔时间；新服务器默认UTC，如果不改数据库时区，写入timestamp without timezone字段的时间会变成UTC，和旧数据产生偏移，直接导致应用显示的时间错误。修改数据库时区后，数据库层面的时间生成逻辑和旧系统完全一致，不需要修改大量表默认值和查询代码。
• 最小化迁移风险：相比手动修改所有用到NOW()的表结构和查询语句（比如替换成NOW() AT TIME ZONE 'Europe/Brussels'），修改数据库时区是一次性操作，成本低且不易遗漏。

关键注意事项 #

• 同步应用层时区设置：确保PHP的date.timezone配置也设为Europe/Brussels，避免应用层和数据库层时区不一致，导致时间转换出现问题。
• 验证时间逻辑：迁移后重点测试时间相关的功能，比如记录创建时间、定时任务触发、报表统计等，确保和旧系统的时间表现完全一致。
• 理解timestamp without timezone的特性：这类字段存储的是「本地时间」，数据库时区决定了写入时的时间值，只要你的应用始终按布鲁塞尔时间读取和展示，就不会有歧义。

总结 #

在你这种单时区服务的场景下，修改数据库默认时区是完全安全且高效的选择，不用被通用场景的建议束缚。

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