fix(dashboard): incorrect time conversion in MySQL#1058
fix(dashboard): incorrect time conversion in MySQL#1058looplj merged 1 commit intolooplj:release/v0.9.xfrom
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 此拉取请求旨在解决 MySQL 数据库中时间转换不准确导致仪表盘数据展示异常的问题。通过优化 MySQL 查询中 Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
431e192 to
2aebfba
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
这个 PR 修复了在某些 MySQL 环境下因缺少时区文件而导致的 CONVERT_TZ 函数问题,通过将命名时区(如 Asia/Shanghai)改为使用 UTC 偏移量(如 +08:00)来提高兼容性。同时,还将 DATE() 函数改为 DATE_FORMAT() 以确保返回的是格式化后的日期字符串,避免了 Go 在类型转换时产生非预期的带有时区信息的时间戳。整体修改是正确的,并且与 PR 描述的目标一致。我有一个关于 FormatUTCOffset 函数实现的改进建议,可以让代码更简洁和地道。
2aebfba to
21384c0
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
此拉取请求通过将命名时区(例如 'Asia/Shanghai')替换为 UTC 偏移格式(例如 '+08:00'),解决了 MySQL 中的时区转换问题。这提高了与未安装时区文件的 MySQL 环境的兼容性。为此,引入了一个新的辅助函数 xtime.FormatUTCOffset 并附有相应的测试。此更改还统一了 MySQL 查询的日期格式字符串,以防止在 Go 中出现与类型相关的问题,具体细节已在拉取请求描述中说明。这些更改实现得很好,有效地解决了问题。我没有其他意见。
|
AI 真好用啊 (x |
|
ci 挂了 |
21384c0 to
c6ea0a2
Compare
c6ea0a2 to
a761e82
Compare
|
CI 好了 |
在 MySQL 中,CONVERT_TZ 函数的
from_tz和to_tz可以使用+08:00以及Asia/Shanghai形式但是如果使用命名时区,需要提前将时区文件导入进来,这并非默认配置
我所使用的是类似 MySQL As A Service 的服务,我没有 root 权限,服务器也没有预设这个时区文件,因此我不能使用命名时区的写法
所以我将其改为了更具有兼容性的写法
internal/server/gql/dashboard_helpers.go中我把他从DATE改成了DATE_FORMAT形式,虽然最后这个语句运行得到的都是2026-03-11,但是前者的类型是 Date,Go 会先转换为 time.Time 再转换为字符串,最后会得到2026-03-11T00:00:00+08:00这样一个东西。因而在进行「最佳渠道性能」的展示时就会有问题,在
buildChannelPerformanceResponse方法中,把 statsMap 的 key 用2026-03-11T00:00:00+08:00和2026-03-11进行等于比较,显然不存在修复前
修复后 每日概览 最佳模型性能 最佳渠道性能 均有数据