[BUG]系统统计时间的问题

[keleus]

当前系统统计时间有2个标准：

1. 仪表盘-使用统计：好像是采用的浏览器本地时间，显示的对应的消耗是按用户所在的UTC+8时间
2. 使用记录：筛选条件选择的日期好像是服务器的UTC时间？没验证过。

具体表现：像现在是 北京时间2025年12月6日00:49，仪表盘上的使用统计是0点的曲线开始上升记录用量。但在使用记录筛选的条件里，选择12月6日搜不到数据，当前在请求的数据在12月5日里可以搜到。

[ding113]

感谢报告此问题! 👋

我分析了代码后发现，系统的时区处理实际上是一致的——仪表盘统计和使用记录筛选都使用服务器端配置的时区（TZ 环境变量，默认为 Asia/Shanghai）。

🔍 具体机制

1. 仪表盘使用统计（src/repository/statistics.ts）：

• 使用 PostgreSQL 的 AT TIME ZONE 转换
• 日期边界基于配置的时区计算（DATE_TRUNC('day', TIMEZONE(${timezone}, NOW()))）
• 返回的时间戳是无时区的本地时间

2. 使用记录筛选（src/repository/usage-logs.ts）：

• 同样使用 AT TIME ZONE 转换
• 前端传递纯日期字符串（如 "2025-12-06"），避免浏览器时区问题
• SQL: (created_at AT TIME ZONE 'UTC' AT TIME ZONE ${timezone})::timestamp

⚠️ 可能的问题原因

您描述的现象（仪表盘显示12月6日数据，但使用记录12月6日搜不到）可能是由于：

1. 图表 X 轴显示问题：仪表盘返回的日期经过 new Date() 解析后，可能被浏览器按本地时区再次转换显示。在 src/app/[locale]/dashboard/_components/statistics/chart.tsx:230-241 中，日期格式化使用了：

   const date = new Date(dateStr);
   return date.toLocaleDateString("zh-CN", {...});

   这里 new Date(dateStr) 的行为取决于 dateStr 的格式——如果是 "2025-12-06" 格式，会被解析为 UTC 午夜时间，然后在 UTC+8 显示为 12月6日08:00。

2. 使用记录日期选择器：前端在 usage-logs-filters.tsx:162-163 中会将选择的结束日期加一天：

   const nextDay = addDays(endDate, 1);
   endDateLocal: `${format(nextDay, "yyyy-MM-dd")}T00:00`

   这是为了实现"包含当天全部数据"的效果。

🔧 建议排查步骤

1. 确认 TZ 环境变量：检查您的部署配置中 TZ 是否设置为 Asia/Shanghai

   docker exec <container> env | grep TZ

2. 检查数据库时区：确认 PostgreSQL 时区配置一致

   SHOW timezone;

3. 对比具体记录：在使用记录页面，取消日期筛选，查看最新请求的 createdAt 时间戳是否符合预期

📝 总结

根据代码分析，后端的时区处理是一致的，但前端图表显示可能存在二次时区转换问题。如果您能提供：

• Docker/部署环境的时区配置
• PostgreSQL 数据库的时区设置
• 浏览器开发者工具中的具体数据（API 返回的原始时间戳）

这将有助于进一步定位问题根源。

---

如果您确认这是一个需要修复的 bug，请回复 @claude please fix this，我可以帮助创建修复方案。

---

🤖 This is an automated response from Claude AI

[ding113]

分析确认 ✅

我已经审查了相关代码，确认 @ding113 的分析是准确的。

问题根源

在 src/app/[locale]/dashboard/_components/statistics/chart.tsx:230 中：

const formatDate = (dateStr: string) => {
  const date = new Date(dateStr);  // <- 这里是问题所在
  // ...
}

当后端返回日期格式如 "2025-12-06"（无时区信息）时，new Date() 会将其解析为 UTC 午夜 00:00。然后在浏览器显示时会转换为本地时区（UTC+8），导致显示偏差。

后端时区处理是正确的

• 仪表盘统计 (statistics.ts): 使用 AT TIME ZONE 正确转换
• 使用记录筛选 (usage-logs.ts): 同样使用时区转换，前端传递本地时间字符串

潜在修复方案

1. 方案 A: 后端返回 ISO 格式带时区的时间戳
2. 方案 B: 前端解析时显式指定时区，避免 new Date() 的 UTC 默认行为
3. 方案 C: 使用 date-fns-tz 或类似库处理时区转换

---

如果您确认遇到了此问题并希望我们修复，请回复 @claude please fix this。

我们也欢迎您提供更多调试信息（如 TZ 环境变量配置、API 返回的原始数据），这将帮助我们更精确地定位和解决问题。

---

🤖 Response from Claude AI

[keleus]

补充，CCH项目前端页面上请求到后端的时间是：/dashboard/logs?startDate=2025-12-06T00%3A00&endDate=2025-12-07T00%3A00&_rsc=1lz9t

换算成UTC+8是2025-12-06 08:00 UTC+8 到 2025-12-07 08:00 UTC+8；感觉是前端组件的问题

[keleus]

@claude please fix this；建议前后端交互使用毫秒级时间戳，时区仅在后端转换查询时处理。

[ding113]

修复已提交 ✅

感谢 @keleus 提供的详细调试信息！我已经创建了一个修复 PR: #275

问题根源确认

经过分析，问题确实出在前端图表组件 chart.tsx 的日期解析逻辑：

// 修复前
const date = new Date(dateStr);  // "2025-12-06" 被解析为 UTC 午夜

当后端返回纯日期字符串（如 "2025-12-06"）时，JavaScript 的 Date 构造函数会将其解析为 UTC 午夜 00:00，而不是本地时间午夜。这导致在 UTC+8 时区显示时会出现 8 小时偏移。

修复方案

添加了 parseLocalDate 辅助函数，手动解析日期字符串为本地 Date 对象：

function parseLocalDate(dateStr: string): Date {
  const normalized = dateStr.replace("T", " ").split(" ");
  const [year, month, day] = normalized[0].split("-").map(Number);
  const timePart = normalized[1]?.split(":").map(Number) || [0, 0, 0];
  return new Date(year, month - 1, day, timePart[0] || 0, timePart[1] || 0, timePart[2] || 0);
}

此函数支持多种日期格式：

• "2025-12-06" - 纯日期
• "2025-12-06T00:00" - ISO 格式
• "2025-12-06 00:00:00" - 带时间的格式

关于使用记录筛选问题

根据您提供的 URL 参数 /dashboard/logs?startDate=2025-12-06T00%3A00&endDate=2025-12-07T00%3A00，后端的时区处理逻辑是正确的——它会将这些参数作为本地时间字符串与数据库中转换后的本地时间进行比较。

如果您在使用记录页面仍然遇到问题，请确认：

1. 服务器的 TZ 环境变量是否设置为 Asia/Shanghai
2. 可以通过 docker exec <container> env | grep TZ 检查

---

🤖 Response from Claude AI

[ding113]

已创建修复 PR ✅

我已按照您的建议实现了修复方案，使用毫秒级时间戳进行前后端交互：

PR: #276

修改内容

1. 前端 (usage-logs-filters.tsx):

   • 日期选择器现在将选中的日期转换为毫秒时间戳
   • startTime: 所选开始日期的 00:00:00.000（浏览器本地时区）
   • endTime: 所选结束日期次日的 00:00:00.000（用于 < 比较）

2. 前端 (usage-logs-view.tsx):

   • URL 参数从 startDate/endDate 改为 startTime/endTime
   • 值为毫秒级 Unix 时间戳

3. 后端 (usage-logs.ts):

   • 接收毫秒时间戳，转换为 ISO 字符串进行 PostgreSQL 查询
   • 移除了不再需要的时区相关代码

技术原理

修复前：
浏览器(UTC+8) 选择 "2025-12-06" → 发送 "2025-12-06T00:00"
服务器 解析为 "2025-12-06 00:00 Asia/Shanghai"
问题：如果浏览器时区不同，返回错误数据

修复后：
浏览器(UTC+8) 选择 "2025-12-06" → 发送 1733414400000 (毫秒时间戳)
服务器 转换为 "2025-12-05T16:00:00.000Z" → 与数据库比较
结果：无论浏览器/服务器时区如何，都能正确查询

测试建议

1. 在使用记录页面选择日期范围
2. 验证 URL 参数显示为 startTime 和 endTime 毫秒时间戳
3. 验证查询结果与仪表盘统计一致
4. 在午夜边界时间（如北京时间 00:00-01:00）测试

---

🤖 Response from Claude AI

[keleus]

@ding113 感觉修复的方式略有奇怪。时间选择组件上的时区如果还是按UTC的话，最后的毫秒级时间戳可能还是错的。