[libc] fix: gmtime_r mishandles timestamps before the epoch by Yunlk · Pull Request #11929 · RT-Thread/rt-thread

Yunlk · 2026-10-24T17:23:38Z

拉取/合并请求描述：(PR description)

[

为什么提交这份PR (why to submit this PR)

修复 #11923。

gmtime_r() 用 C 的除法拆时间戳，而 C 的除法向零截断：

work = *timep % (24*60*60);          /* *timep < 0 时余数为负 */
work = (int)(*timep / (24*60*60));   /* 天数也是负的 */
for (i = 1970;; ++i) { ... }         /* 只能向未来遍历 */

于是负时间戳会返回一个非 NULL、但字段非法的结构体：

t	master 实际	期望
-1	`1970-01-01 00:00:-1`（wday=4 yday=0）	`1969-12-31 23:59:59`
-86400	`1970-01-00 00:00:00`（yday=-1）	`1969-12-31 00:00:00`
-31536000	`1970-01--364 00:00:00`（wday=-4 yday=-365）	`1969-01-01 00:00:00`
-2208988800	`1970-01--25566 00:00:00`（wday=-6 yday=-25567）	`1900-01-01 00:00:00`

不只是秒为负，tm_mday 和 tm_wday 也会变成明显的非法值。

你的解决方案是什么 (what is your solution)

只改 gmtime_r() 一个函数，三步：

改 floor 除法：余数为负时借一天，保证 tm_sec/tm_min/tm_hour 非负
tm_wday 用规范化后的天数计算，并保证结果落在 0~6（原来 (4 + work) % 7 在天数为负时返回负值）
年份遍历支持后退：while (work < 0) { --i; work += 闰年?366:365; }，让早于 1970 的时间戳也能定位到正确年份

__isleap() 对 1970 之前的年份本身就有效，直接复用。

请提供验证的bsp和config (provide the config and bsp)

BSP: bsp/qemu-vexpress-a9（sizeof(time_t)=8）
.config: BSP 默认配置，未改动
action: 未使用 GitHub Actions；本地 QEMU 11.0.0 + arm-none-eabi-gcc 15.2.1，master 1c801efa

同一份固件、同一个探针，改前/改后各跑一次：

t	master	本 PR
0	1970-01-01 00:00:00 wday=4	1970-01-01 00:00:00 wday=4
86399	1970-01-01 23:59:59 wday=4	1970-01-01 23:59:59 wday=4
86400	1970-01-02 00:00:00 wday=5	1970-01-02 00:00:00 wday=5
-1	1970-01-01 00:00:-1 wday=4	1969-12-31 23:59:59 wday=3
-86400	1970-01-00 00:00:00 wday=3	1969-12-31 00:00:00 wday=3
-31536000	1970-01--364 wday=-4	1969-01-01 00:00:00 wday=3
-2208988800	1970-01--25566 wday=-6	1900-01-01 00:00:00 wday=1（周一）

非负时间戳行为完全未变；1900-01-01 的 wday=1（周一）也对。

两点未包含的内容

int work 的类型没改。天数在进入年份循环时仍转 int，对 64 位 time_t 的极端值（超过约 ±580 万年）依然会截断。glibc 在那种情况下返回 EOVERFLOW，但这与 [Bug] [libc] gmtime_r 对负时间戳返回非法日历字段 #11923 是两件事，没有混进本次改动。
utest 暂未加入。可以在 components/libc/compilers/common/utest/time_tc.c 里挂 -1 与 -86400 两个用例，但需要先确认它归属哪个 Kconfig、以及哪些跑 utest 的 BSP 会执行到。若维护者认可当前改法，我可以补上用例后更新本 PR。

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

已经仔细查看过代码改动的对比 Already check the difference between PR and old code
代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
代码是高质量的 Code in this PR is of high quality
已经使用clang-format 源码格式化工具确保格式符合RT-Thread代码规范 This PR has been formatted with clang-format and complies with RT-Thread code specification
如果是新增bsp, 已经添加ci检查到.github/ALL_BSP_COMPILE.json 详细请参考链接BSP自查

gmtime_r() split the timestamp with C division, which truncates toward zero: work = *timep % (24*60*60); /* negative remainder for *timep < 0 */ work = (int)(*timep / (24*60*60)); For a negative timestamp both the day count and the remainder come out negative, and the year loop below could only walk forward from 1970, so the result was returned as a valid struct tm holding impossible fields: -1 -> 1970-01-01 00:00:-1 (want 1969-12-31 23:59:59) -86400 -> 1970-01-00 00:00:00 (want 1969-12-31 00:00:00) -31536000 -> 1970-01--364 00:00:00 (want 1969-01-01 00:00:00) -2208988800 -> 1970-01--25566 00:00:00 (want 1900-01-01 00:00:00) Normalise to floor division first (borrow one day when the remainder is negative), compute tm_wday from the normalised day count while keeping the modulo result non-negative, and let the year walk run backwards for negative day counts. Verified on bsp/qemu-vexpress-a9 (QEMU 11.0.0, arm-none-eabi-gcc 15.2.1, sizeof(time_t) = 8), same probe run against master and against this patch: t master patched 0 1970-01-01 00:00:00 wday=4 1970-01-01 00:00:00 wday=4 86399 1970-01-01 23:59:59 wday=4 1970-01-01 23:59:59 wday=4 86400 1970-01-02 00:00:00 wday=5 1970-01-02 00:00:00 wday=5 -1 1970-01-01 00:00:-1 wday=4 1969-12-31 23:59:59 wday=3 -86400 1970-01-00 00:00:00 wday=3 1969-12-31 00:00:00 wday=3 -31536000 1970-01--364 wday=-4 1969-01-01 00:00:00 wday=3 -2208988800 1970-01--25566 wday=-6 1900-01-01 00:00:00 wday=1 Non-negative timestamps are unchanged; 1900-01-01 correctly reports Monday. Refs RT-Thread#11923

github-actions · 2026-10-24T17:25:04Z

👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread!

为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。
To ensure your code complies with RT-Thread's coding style, please run the code formatting workflow by following the steps below (If the formatting of CI fails to run).

🛠 操作步骤 | Steps

前往 Actions 页面 | Go to the Actions page
点击进入工作流 → | Click to open workflow →
点击 Run workflow | Click Run workflow

Use workflow from 保持默认分支（通常为 master）
Keep the default branch (usually master) in Use workflow from
在 branch 输入框填写 PR 分支 fix/gmtime-r-negative
Enter PR branch fix/gmtime-r-negative in the branch field
设置需排除的文件/目录（目录请以"/"结尾）
Set files/directories to exclude (directories should end with "/")

等待工作流完成 | Wait for the workflow to complete
格式化后的代码将作为独立提交推送至你的分支。
The formatting changes will be pushed to your branch as a separate commit.

完成后，提交将自动更新至 fix/gmtime-r-negative 分支，关联的 Pull Request 也会同步更新。
Once completed, commits will be pushed to the fix/gmtime-r-negative branch automatically, and the related Pull Request will be updated.

如有问题欢迎联系我们，再次感谢您的贡献！💐
If you have any questions, feel free to reach out. Thanks again for your contribution!

github-actions · 2026-10-24T17:27:23Z

📌 Code Review Assignment

🏷️ Tag: components

Reviewers: @Maihuanyi

Changed Files (Click to expand)

components/libc/compilers/common/ctime.c
components/libc/compilers/common/utest/time_tc.c

🏷️ Tag: components_libc

Reviewers: @GorrayLi @mysterywolf

Changed Files (Click to expand)

components/libc/compilers/common/ctime.c
components/libc/compilers/common/utest/time_tc.c

📊 Current Review Status (Last Updated: 2026-10-26 14:38 CST)

⌛ @GorrayLi Pending Review
⌛ @Maihuanyi Pending Review
⌛ @mysterywolf Pending Review

📝 Review Instructions

维护者可以通过单击此处来刷新审查状态: 🔄 刷新状态
Maintainers can refresh the review status by clicking here: 🔄 Refresh Status
确认审核通过后评论 LGTM/lgtm
Comment LGTM/lgtm after confirming approval
PR合并前需至少一位维护者确认
PR must be confirmed by at least one maintainer before merging

ℹ️ 刷新CI状态操作需要具备仓库写入权限。
ℹ️ Refresh CI status operation requires repository Write permission.

github-actions · 2026-10-24T19:55:18Z

MemBrowse Memory Report · Explore what changed →

k230

SRAM: .bss +4,096 B, .data +8 B, .eh_frame +13,600 B, .sbss +112 B, .srodata.cst8 +8 B, .stack -8 B, .text +62,632 B (+7.1%, 1,208,996 B / 268,300,288 B, total: 0% used)

loongson-ls1cdev

Code: .text +264 B (+0.1%, 363,624 B)

nuvoton-m487

CODE: .text +112 B (+0.0%, 356,288 B / 524,288 B, total: 68% used)

simulator

Code: .rela.dyn +600 B, .rodata +96 B, .text +552 B (+0.0%, 2,674,268 B)
Data: .data +640 B (+0.0%, 1,609,924 B)

wch-ch32v208w-r0

FLASH: .text +280 B (+0.2%, 159,880 B / 491,520 B, total: 33% used)

x86

Code: .text +128 B (+0.1%, 199,053 B)

No memory changes detected for:

_{Catch memory regressions in CI with MemBrowse. Free for open source.}

CYFS3 · 2026-10-26T02:09:17Z

可以增加一下utest的测试。
增加 -1、-86400、-86401、1968 年闰日和纪元零点，检查全部日期字段及 tm_wday/tm_yday

Requested in the review of RT-Thread#11929: pin down gmtime_r() behaviour before 1970. Adds five cases to the existing components.libc.time testcase and checks every field the function fills in, including tm_wday and tm_yday: timestamp expected 0 1970-01-01 00:00:00 wday=4 yday=0 -1 1969-12-31 23:59:59 wday=3 yday=364 -86400 1969-12-31 00:00:00 wday=3 yday=364 -86401 1969-12-30 23:59:59 wday=2 yday=363 -58060800 1968-02-29 00:00:00 wday=4 yday=59 (1968 leap day) Without the fix in the previous commit the new unit fails on every one of the five cases, with all eight field assertions reported, so the test does pin the behaviour down rather than passing by accident: t = -1 1970-01-01 00:00:-1 wday=4 yday=0 t = -86400 1970-01-00 00:00:00 wday=3 yday=-1 t = -86401 1970-01-00 00:00:-1 wday=3 yday=-1 Verified on bsp/qemu-vexpress-a9 with RT_UTEST_LIBC_TIME enabled: with the fix : [ PASSED ] testcase (components.libc.time) without the fix : all five cases FAILED Refs RT-Thread#11923 Refs RT-Thread#11929

Yunlk · 2026-10-26T06:38:40Z

已按你的要求补上 utest，提交 3b77a8ad9 已推送到本分支。

加在哪

components/libc/compilers/common/utest/time_tc.c，挂在已有的 components.libc.time 测试用例下（新增一个 UTEST_UNIT_RUN(gmtime_r_before_epoch_test)），Kconfig 沿用 RT_UTEST_LIBC_TIME。

覆盖的五个点

按你说的清单逐条对应：

timestamp	期望
0（纪元零点）	1970-01-01 00:00:00，wday=4，yday=0
-1	1969-12-31 23:59:59，wday=3，yday=364
-86400	1969-12-31 00:00:00，wday=3，yday=364
-86401	1969-12-30 23:59:59，wday=2，yday=363
-58060800（1968 闰日 2/29）	1968-02-29 00:00:00，wday=4，yday=59

全部日期字段都断言，不只看年月日：tm_year / tm_mon / tm_mday / tm_hour / tm_min / tm_sec / tm_wday / tm_yday 八个逐一比对。之所以连 wday/yday 一起断言，是因为原实现的坏值正好出在这两个字段上（wday 会变成 -4、-6，yday 会变成 -365、-25567），只查日期的话抓不到。

-58060800 是 1968-02-29 到纪元的距离：1968 是闰年，该年剩 307 天 + 1969 的 365 天 = 672 天，672×86400 = 58060800。

验证：用例确实有鉴别力

这是我觉得更需要说明的一点——新用例在未修复的 master 上会失败，不是恒真断言：

带修复：

[I/utest] epoch zero: 1970-01-01 00:00:00 wday=4 yday=0
[I/utest] t = -1: 1969-12-31 23:59:59 wday=3 yday=364
[I/utest] t = -86400: 1969-12-31 00:00:00 wday=3 yday=364
[I/utest] t = -86401: 1969-12-30 23:59:59 wday=2 yday=363
[I/utest] 1968 leap day: 1968-02-29 00:00:00 wday=4 yday=59
[I/utest] [  PASSED  ] [ result   ] testcase (components.libc.time)

不带修复（仅把 ctime.c 回退到 master，utest 不变）：

[I/utest] t = -1: 1970-01-01 00:00:-1 wday=4 yday=0
[E/utest] [  ASSERT  ] msg: ((r.tm_year) not == (c->year))
[E/utest] [  ASSERT  ] msg: ((r.tm_mon) not == (c->mon))
[E/utest] [  ASSERT  ] msg: ((r.tm_mday) not == (c->mday))
[E/utest] [  ASSERT  ] msg: ((r.tm_hour) not == (c->hour))
[E/utest] [  ASSERT  ] msg: ((r.tm_min) not == (c->min))
[E/utest] [  ASSERT  ] msg: ((r.tm_sec) not == (c->sec))
[E/utest] [  ASSERT  ] msg: ((r.tm_wday) not == (c->wday))
[E/utest] [  ASSERT  ] msg: ((r.tm_yday) not == (c->yday))

[I/utest] t = -86400: 1970-01-00 00:00:00 wday=3 yday=-1
...（同样八条全失败）

[I/utest] t = -86401: 1970-01-00 00:00:-1 wday=3 yday=-1

五个用例每个都是八条断言全失败，说明用例确实锁住了这个缺陷。

环境：bsp/qemu-vexpress-a9，RT_UTEST_LIBC_TIME=y，QEMU 11.0.0，arm-none-eabi-gcc 15.2.1。

另外

之前 issue 里提到的 int work 类型问题（64 位 time_t 算出的天数仍会截断到 int）本次没有处理，也没有加对应用例——那属于 EOVERFLOW 那种另一个层面的处理，不适合混在这个补丁里。如果希望一并覆盖，可以说明，我另开一条处理。

Yunlk requested a review from mysterywolf as a code owner October 24, 2026 17:23

github-actions Bot added the Component label Oct 24, 2026

Yunlk mentioned this pull request Oct 28, 2026

[libc] fix: validate settimeofday fields by their own type #11928

Open

6 of 10 tasks

Navigation Menu

Repository navigation

[libc] fix: gmtime_r mishandles timestamps before the epoch - #11929

[libc] fix: gmtime_r mishandles timestamps before the epoch#11929
Yunlk wants to merge 2 commits into
RT-Thread:masterfrom
Yunlk:fix/gmtime-r-negative

Yunlk commented Oct 24, 2026

Uh oh!

github-actions Bot commented Oct 24, 2026

Uh oh!

github-actions Bot commented Oct 24, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 24, 2026 •

edited

Loading

Uh oh!

CYFS3 commented Oct 26, 2026

Uh oh!

Yunlk commented Oct 26, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Yunlk commented Oct 24, 2026

拉取/合并请求描述：(PR description)

为什么提交这份PR (why to submit this PR)

你的解决方案是什么 (what is your solution)

请提供验证的bsp和config (provide the config and bsp)

两点未包含的内容

当前拉取/合并请求的状态 Intent for your PR

代码质量 Code Quality：

Uh oh!

github-actions Bot commented Oct 24, 2026

🛠 操作步骤 | Steps

Uh oh!

github-actions Bot commented Oct 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📌 Code Review Assignment

🏷️ Tag: components

🏷️ Tag: components_libc

📊 Current Review Status (Last Updated: 2026-10-26 14:38 CST)

📝 Review Instructions

Uh oh!

github-actions Bot commented Oct 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

MemBrowse Memory Report · Explore what changed →

k230

loongson-ls1cdev

nuvoton-m487

simulator

wch-ch32v208w-r0

x86

Uh oh!

CYFS3 commented Oct 26, 2026

Uh oh!

Yunlk commented Oct 26, 2026

加在哪

覆盖的五个点

验证：用例确实有鉴别力

另外

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions Bot commented Oct 24, 2026 •

edited

Loading

github-actions Bot commented Oct 24, 2026 •

edited

Loading