[fix][kernel] fix timegm month overflow calculation - #11720
Conversation
|
|
|
👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread! 为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。 🛠 操作步骤 | Steps
完成后，提交将自动更新至 如有问题欢迎联系我们，再次感谢您的贡献！💐 |
📌 Code Review Assignment🏷️ Tag: componentsReviewers: @Maihuanyi Changed Files (Click to expand)
🏷️ Tag: components_libcReviewers: @GorrayLi @mysterywolf Changed Files (Click to expand)
🏷️ Tag: workflowReviewers: @Rbb666 @kurisaW @supperthomas Changed Files (Click to expand)
📊 Current Review Status (Last Updated: 2026-08-20 19:06 CST)
📝 Review Instructions
|
45041bb to
9ac763e
Compare
|
00764ae to
60cc901
Compare
|
ToolsCI 的失败看起来与本 PR 无关。 当前失败来自最近加入 RT-Thread/packages 的 ai/LiME-TM/Kconfig： warning: default on the choice symbol LIME_TM_USING_MNIST_FS_EXAMPLE LiME-TM 是今天由 commit 69de99ddb0b8 加入 packages 的，目前 choice 下的两个 symbol 使用了 default n / default y，kconfiglib 会对此产生 warning。 而 ToolsCI 当前会把任意 Kconfig warning 当成错误并直接失败，因此这里需要先修复 LiME-TM 的 Kconfig，之后再重新运行 ToolsCI。 本 PR 修改的是 timegm() 及对应 utest，与上述 package Kconfig warning 无关。 |
60cc901 to
74d5bf4
Compare
|
有两个问题：
建议调整为： 同时：
|
74d5bf4 to
d2e3763
Compare
done |
|
看到测试用例已经运行了，建议在用例中添加点LOG，这样可以直观的看到输出结果 
|
The original overflow logic used __spm[tm_mon] as the current month's length when normalizing tm_mday. This produced incorrect dates after crossing month boundaries and left zero or negative days unnormalized. Use the difference between adjacent cumulative day offsets with leap-year handling. Normalize overflow in tm_sec, tm_min, tm_hour, tm_mday, and tm_mon to keep the affected broken-down fields normalized. Add regression tests for month boundaries, leap years, large offsets, zero and negative days, negative time fields, combined overflow, and boundary carry cases. Close RT-Thread#11686 Signed-off-by: Hui Su <3164683437@qq.com>
d2e3763 to
470bda4
Compare
测试日志： done |
3 participants
When normalizing tm_mday, the original code used cumulative day offsets
from __spm[] as if they were the length of the current month. This caused
incorrect dates after crossing month boundaries. For example,
2026/08/05 + 420 days was normalized to 2027/03/01 instead of
2027/09/29.
The existing normalization also did not handle zero or negative tm_mday
values, leaving the broken-down time fields unnormalized.
Use the difference between adjacent __spm[] entries to obtain the actual
month length, with leap-year handling for February. Add backward
normalization for zero and negative days, and normalize negative
tm_sec, tm_min, tm_hour, and tm_mon values consistently with the existing
positive overflow handling.
Add regression tests covering month boundaries, leap years, large day
offsets, zero and negative days, negative time fields, carry boundaries,
combined overflow, and timestamp round-trip consistency.
Close #11686
拉取/合并请求描述：(PR description)
为什么提交这份PR (why to submit this PR)
修复 timegm() 在日期字段越界时的归一化错误（Issue #11686）。
原实现使用 __spm[] 的累计天数作为当前月份长度，导致 tm_mday 跨月时计算错误。
例如 2026/08/05 加 420 天，预期结果为 2027/09/29，实际却得到
2027/03/01。
此外，tm_mday 为 0 或负数时也没有向前归一化，可能导致返回时间戳与
struct tm 中的日期字段不一致。
你的解决方案是什么 (what is your solution)
使用 __spm[mon + 1] - __spm[mon] 计算当前月份的实际天数，并正确处理
闰年二月。
增加 tm_mday <= 0 时向前回退月份和年份的归一化逻辑，同时补充
tm_sec、tm_min、tm_hour 和 tm_mon 的负值归一化，使其与已有的正向
越界处理保持一致。
新增 src/utest/time_tc.c 回归测试，覆盖：
请提供验证的bsp和config (provide the config and bsp)
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality：
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up