GCC 9.4与12.1中std::tm的tm_wday行为差异问询

你遇到的这个问题，根源并非GCC本身的变更，而是底层glibc库的strptime实现更新——Ubuntu 20.04使用glibc 2.31，Ubuntu 22.04升级到了glibc 2.35，而std::get_time的底层实现依赖于glibc的strptime函数。

关键原因拆解 #

1. 标准定义的模糊点：
   C++标准中，std::get_time的行为等价于C语言的strptime。对于未包含%w（星期几数字）或%a（星期几缩写）的格式字符串（比如你的%Y-%m-%d %H:%M:%S），是否自动计算并设置tm_wday是实现定义的，并非强制要求。

2. glibc的行为变更：

   • 在glibc 2.31及更早版本中，strptime解析日期时不会主动计算tm_wday，因此你的代码中std::tm timeinfo = {}初始化后，tm_wday保持初始值0。
   • 升级到glibc 2.35后，strptime新增了根据解析出的年、月、日自动计算并填充tm_wday的逻辑，此时周一（2019-02-18确实是周一）会被正确设置为1（符合C++标准：0代表周日）。

验证与解决方案 #

• 在旧环境中调用mktime(&timeinfo)后，tm_wday会被修正为正确的值（1）——mktime的标准行为就是根据日期字段规范化tm结构体，包括计算星期几和闰年调整。
• 正确的做法是永远依赖mktime来获取可靠的tm_wday值，而不是直接使用std::get_time解析后的结果，因为后者的行为存在实现差异，不具备跨版本/跨平台一致性。

补充说明 #

由于这个变更属于glibc而非GCC的更新，因此你在GCC的变更日志中找不到相关记录。你可以查看glibc的更新文档，确认strptime在2.31到2.35之间的行为调整。

内容的提问来源于stack exchange，提问作者Yigit Yasar