Sequelize 默认使用 UTC 时区解析时间，而 PostgreSQL 服务器可能配置为本地时区（如 +01:00），导致 CURRENT_TIME 与 now() 返回值在 JavaScript 端显示不一致；需显式配置 timezone 选项以对齐数据库实际时区。
sequelize 默认使用 utc 时区解析时间，而 postgresql 服务器可能配置为本地时区（如 +01:00），导致 `current_time` 与 `now()` 返回值在 javascript 端显示不一致；需显式配置 `timezone` 选项以对齐数据库实际时区。
在使用 Sequelize 连接 PostgreSQL 时，你可能会遇到时间值“看起来不一致”的现象：例如执行原生 SQL 查询 SELECT CURRENT_TIME 和 SELECT NOW()，返回的时间字符串或 Date 对象时区偏移不同（如 +02 vs Z），甚至与 pgAdmin 中直接查询的结果不符。这并非数据库行为异常，而是 Sequelize 在结果解析阶段对时间类型的默认处理逻辑所致。
Sequelize 默认将所有 TIMESTAMP WITH TIME ZONE（即 timestamptz）字段解析为 UTC 时间（即 new Date(...).toISOString() 格式），并忽略数据库会话的实际时区设置。即使你的 PostgreSQL 服务器、操作系统及 postgresql.conf 均设为 Europe/Berlin（GMT+1/+2）或显式 timezone = 'CET'，Sequelize 的 JavaScript 客户端仍会强制转换为 UTC——除非你主动告知它应以何种时区解释服务端返回的时间戳。
✅ 正确做法是在初始化 Sequelize 实例时，通过 timezone 配置项显式声明目标时区：
const sequelize = new Sequelize(
process.env.DB_DATABASE,
process.env.DB_USERNAME,
process.env.DB_PASSWORD,
{
host: process.env.DB_SERVER,
port: process.env.DB_PORT,
dialect: 'postgres',
timezone: '+01:00', // ← 关键：与数据库实际时区严格一致（夏令时需注意！）
pool: {
min: 0,
max: 5,
idle: 10_000,
acquire: 30_000
}
}
);
⚠️ 注意事项：
-
timezone值必须是 ISO 8601 偏移格式（如'+01:00'），不支持区域名（如'Europe/Berlin'）——后者仅在 PostgreSQL 服务端生效，Sequelize 不识别； - 若服务器启用夏令时（DST），
+01:00在冬令时有效，但夏令时应为+02:00；若需自动适配，建议统一使用'Z'（UTC）并在应用层做时区转换，或通过pg驱动级配置（如options.timezone = 'auto'）配合moment-timezone处理； - 该配置仅影响 从数据库读取时间字段时的解析行为，不影响 SQL 中
NOW()或CURRENT_TIME的服务端计算逻辑（它们始终按数据库会话时区返回）； - 对于写入操作，Sequelize 会将 JS
Date对象按timezone配置反向转换后发送至数据库，确保双向时区语义一致。
? 验证是否生效：
执行以下代码，观察输出是否统一为预期时区（如 +01:00）：
const [currentTime] = await sequelize.query("SELECT CURRENT_TIME");
const [nowTime] = await sequelize.query("SELECT NOW()");
console.log('CURRENT_TIME:', currentTime[0].current_time); // 应含 '+01:00'
console.log('NOW():', nowTime[0].now.toISOString()); // 若 timezone: '+01:00'，则 .toISOString() 仍为 UTC，但 .toString() 会反映本地化偏移
总结：Sequelize 的时区错位本质是客户端解析策略与服务端环境脱节所致。通过显式声明 timezone，可确保时间数据在序列化/反序列化过程中保持语义一致，避免业务逻辑中因时间偏移引发的条件误判、定时任务偏差或日志时间混乱等问题。
