1. 从两个占位符说起为什么需要动态时间标记第一次在项目里看到__DATE__和__TIME__这两个词很多人会以为它们是某个框架自定义的模板变量或者是构建工具里约定俗成的占位符。实际上它们是C/C 预处理器内置的标准宏由编译器在预处理阶段自动展开不需要任何头文件也不需要手动定义。这一点非常关键——它意味着你可以在任何符合标准的 C/C 编译器上直接使用它们无论是 GCC、Clang 还是 MSVC行为基本一致。那它们到底解决什么问题简单说就是把编译发生的那一刻固化进程序里。程序运行的时候你没法直接问操作系统我是什么时候被编译出来的因为可执行文件本身不记录这个信息。但很多场景又确实需要知道构建时间比如排查线上问题时你需要确认服务器上跑的二进制到底是哪次构建的产物比如做版本追溯时你想在日志里打一个构建时间戳再比如做固件升级校验时你想对比新旧固件的编译时间来判断是否真的更新了。这些需求__DATE__和__TIME__就是最轻量的答案。它们的展开结果长这样printf(Build date: %s\n, __DATE__); printf(Build time: %s\n, __TIME__);编译后运行输出类似Build date: Jan 15 2025 Build time: 14:32:07注意这里的格式日期是Mmm dd yyyy的形式月份是英文三字母缩写日期如果是个位数会用空格补齐比如Jan 5 20255前面有两个空格时间是hh:mm:ss的 24 小时制。这个格式是标准规定的不是某个编译器的私货所以你可以放心地按这个格式去解析。很多人第一次用会踩的坑就在这里以为日期是2025-01-15这种 ISO 格式结果写解析代码时直接崩了。我见过有同事用sscanf(str, %d-%d-%d, ...)去解析__DATE__跑起来全是乱码排查半天才发现格式对不上。所以第一件事先把格式记牢。提示__DATE__和__TIME__是预处理宏不是运行时的函数调用。它们的值在编译那一刻就固定了程序运行多少次都不会变。如果你需要的是程序启动时间或当前时间那是另一回事得用time()、clock_gettime()之类的运行时接口。2. 展开规则与格式细节那些文档里不会写清楚的地方2.1 日期格式的空格陷阱标准里对__DATE__的格式定义是Mmm dd yyyy其中dd是两位如果日期小于 10前面补空格而不是补零。这个细节极其容易翻车。比如 1 月 5 日展开结果是Jan 5 2025Jan和5之间是两个空格而 1 月 15 日是Jan 15 2025中间只有一个空格。如果你用固定偏移去截取字符串比如str[4]到str[5]取日期那在个位数日期时就会取到空格。正确的做法是用sscanf配合格式串来解析#include stdio.h void parse_build_date(void) { char month_str[4] {0}; int day 0, year 0; // 注意 %3s 读取月份%d 会自动跳过前导空格 sscanf(__DATE__, %3s %d %d, month_str, day, year); printf(Month%s Day%d Year%d\n, month_str, day, year); }%d在scanf系列里会自动跳过前导空白字符所以不管日期是一位还是两位都能正确读出来。这是处理__DATE__最稳妥的方式比手动切字符串可靠得多。2.2 时间是 24 小时制且始终补零__TIME__的格式是hh:mm:ss小时、分钟、秒都是两位不足补零。比如下午 2 点 5 分 3 秒展开是14:05:03。这个格式相对规整用sscanf(str, %d:%d:%d, ...)就能直接解析。但要注意它不包含时区信息也不包含毫秒。它反映的是编译所在机器的本地时间具体是哪个时区取决于编译时的系统设置。这就引出一个重要问题如果你的构建服务器在 UTC 时区而开发者在东八区那么同一份代码在不同机器上编译__TIME__展开的值会差 8 小时。这在跨地域团队协作时会造成困惑。我的建议是如果构建时间要用于正式追溯最好在构建脚本里统一设置时区环境变量比如TZUTC让所有构建产物的时间基准一致。2.3 宏展开发生在预处理阶段理解这一点对排查问题很重要。__DATE__和__TIME__是在预处理阶段就被替换成字符串字面量的也就是说它们在编译单元里就是两个普通的字符串常量。这意味着你不能在运行时改变它们它们是只读的。它们会被编译器当作字符串处理可以参与字符串拼接、比较等操作。如果你把包含这两个宏的代码编译成静态库那么库里的时间就是编译这个库时的时间而不是最终链接可执行文件时的时间。最后一点特别容易踩坑。假设你有一个静态库libcore.a里面用__DATE__打印构建时间。你半年前编译了这个库今天编译主程序并链接它。运行主程序时打印出来的是半年前的日期而不是今天的。因为宏在编译libcore.a的时候就已经固化了。如果你希望时间反映最终可执行文件的构建时刻就必须把宏放在主程序的源文件里或者放在每次都会重新编译的模块里。3. 典型使用场景从版本追溯到底层调试3.1 版本信息与构建追溯这是最常见的用法。在程序的启动日志里打一行构建时间运维和测试人员一看就知道当前跑的是哪个版本。比如void print_version(void) { printf(App Version: 1.4.2\n); printf(Build: %s %s\n, __DATE__, __TIME__); }输出App Version: 1.4.2 Build: Jan 15 2025 14:32:07这比单纯写一个版本号有用得多因为版本号可能忘记更新但构建时间是编译器自动填的不会骗人。我在实际项目里就遇到过版本号写错但构建时间正确的情况最后靠构建时间定位到了正确的二进制。3.2 固件与嵌入式场景在嵌入式开发里__DATE__和__TIME__几乎是标配。因为嵌入式设备通常没有文件系统也没法方便地查看文件修改时间固件里烧录的构建时间就成了唯一的版本标识。很多设备会在上电时通过串口打印一行构建信息产线和售后就靠这个判断固件版本。但嵌入式场景有个特殊问题编译时间不等于烧录时间。你可能今天编译了固件下周才烧录到设备上。所以有些团队会额外加一个烧录时间的记录机制比如在产线工具里写入一个单独的时间戳区域和编译时间区分开。这个经验很实用避免把两个时间混淆。3.3 调试与日志关联在多模块系统里如果每个模块都打印自己的构建时间排查问题时就能快速判断模块之间的版本是否匹配。比如 A 模块是 1 月 10 日构建的B 模块是 1 月 15 日构建的那就要怀疑接口是否兼容。这种时间对齐的思路在微服务架构里也常用只不过微服务通常用镜像标签而不是编译宏。3.4 一个反直觉的用法检测重复编译有些构建系统会缓存编译结果如果源文件没变就不重新编译。但如果你在源文件里用了__DATE__那么每次编译这个文件内容都会变缓存就会失效。这既是缺点也是优点缺点是无法利用编译缓存优点是你可以用它来强制某些文件每次都重新编译。比如你想让版本信息文件每次都更新就可以在里面放__DATE__这样构建系统每次都会重新编译它。4. 跨平台差异与编译器行为对比虽然标准规定了格式但不同编译器在细节上还是有差异。下面这张表是我在实际项目中验证过的结果编译器__DATE__格式__TIME__格式备注GCCMmm dd yyyyhh:mm:ss完全符合标准个位日期补空格ClangMmm dd yyyyhh:mm:ss与 GCC 一致MSVCMmm dd yyyyhh:mm:ss格式一致但受系统区域设置影响较小某些嵌入式编译器Mmm dd yyyyhh:mm:ss个别老版本可能补零而非补空格需要特别注意的是MSVC 在某些区域设置下可能会输出本地化的月份缩写虽然英文环境下是Jan、Feb但如果系统语言不是英文理论上存在差异。不过实际测试中主流版本还是输出英文缩写。为了保险如果你的代码要跨平台解析时最好用月份缩写映射表而不是依赖strptime之类的本地化函数。另一个差异点是时间精度。标准只保证到秒不保证毫秒。有些编译器可能提供扩展宏比如__TIMESTAMP__它包含完整的日期和时间格式类似Tue Jan 15 14:32:07 2025。但这个宏不是标准的一部分可移植性不如__DATE__和__TIME__。如果你需要更完整的时间戳可以优先考虑__TIMESTAMP__但要加平台判断。#ifdef __TIMESTAMP__ printf(Build timestamp: %s\n, __TIMESTAMP__); #else printf(Build: %s %s\n, __DATE__, __TIME__); #endif5. 实战中的坑与规避策略5.1 坑一把编译时间当成运行时间这是新手最容易犯的错误。有人想记录程序启动时间结果用了__TIME__发现每次运行都是同一个值还以为是系统时钟坏了。记住__TIME__是编译时刻不是运行时刻。要记录运行时间用#include time.h time_t now time(NULL); struct tm *local localtime(now); printf(Start time: %02d:%02d:%02d\n, local-tm_hour, local-tm_min, local-tm_sec);5.2 坑二在头文件里使用导致重复定义如果你把__DATE__放在头文件里定义一个全局变量而这个头文件被多个源文件包含就会导致多个编译单元里都有这个变量的定义链接时报重复符号错误。正确做法是在头文件里用extern声明在某个源文件里定义。或者用static const char build_date[] __DATE__;放在头文件里但这样每个编译单元都会有一份副本浪费空间但不会链接错误。更好的做法是提供一个函数在函数内部使用宏返回字符串。// version.h const char* get_build_date(void); // version.c const char* get_build_date(void) { return __DATE__; }5.3 坑三构建缓存导致时间不更新前面提到过如果构建系统有缓存而包含__DATE__的文件没有被重新编译那么时间就不会更新。这在增量构建时很常见。解决办法有两个一是把构建信息单独放在一个总是重新编译的文件里二是在构建脚本里显式删除这个文件的编译产物强制重新编译。我在一个项目里就遇到过CI 流水线跑完产出的二进制里构建时间还是上周的。排查后发现是构建缓存命中了因为源文件没变。后来我们在构建脚本里加了一行touch version.c强制更新时间戳问题就解决了。5.4 坑四时区不一致导致时间对不上跨时区团队协作时构建服务器和开发者的本地时间可能不一致。如果构建时间用于日志分析时区不统一会造成困扰。建议在构建脚本里统一设置TZUTC并在日志里明确标注时区。比如TZUTC make然后在程序里打印时加上UTC后缀printf(Build: %s %s UTC\n, __DATE__, __TIME__);5.5 坑五字符串比较时的格式问题如果你想比较两个构建时间的先后直接字符串比较是不行的因为Mmm格式的月份不是按字母顺序对应时间顺序的。比如Apr在字母表里排在Jan前面但 4 月比 1 月晚。正确做法是解析成time_t再比较#include time.h #include stdio.h time_t parse_build_time(const char *date, const char *time_str) { struct tm tm_build {0}; char month_str[4] {0}; int day, year, hour, min, sec; sscanf(date, %3s %d %d, month_str, day, year); sscanf(time_str, %d:%d:%d, hour, min, sec); const char *months[] {Jan,Feb,Mar,Apr,May,Jun, Jul,Aug,Sep,Oct,Nov,Dec}; int month 0; for (int i 0; i 12; i) { if (strcmp(month_str, months[i]) 0) { month i; break; } } tm_build.tm_year year - 1900; tm_build.tm_mon month; tm_build.tm_mday day; tm_build.tm_hour hour; tm_build.tm_min min; tm_build.tm_sec sec; tm_build.tm_isdst -1; return mktime(tm_build); }这样得到的time_t就可以直接比较大小了。6. 进阶技巧让构建时间更有用6.1 结合版本号生成唯一标识单纯的时间戳可能不够唯一比如同一秒内多次构建。可以结合版本号和构建序号生成一个更可靠的构建 ID#define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) #define BUILD_ID __DATE__ __TIME__ v TOSTRING(VERSION) - TOSTRING(BUILD_NUMBER)这样输出的构建 ID 类似Jan 15 2025 14:32:07 v1.4.2-108既有时间又有版本和序号追溯起来非常方便。6.2 在 CI 中注入额外信息很多 CI 系统允许在编译时传入环境变量比如 Git 提交哈希。你可以把这些信息和__DATE__结合起来#ifndef GIT_COMMIT #define GIT_COMMIT unknown #endif const char* get_full_version(void) { static char buf[256]; snprintf(buf, sizeof(buf), %s %s [%s], __DATE__, __TIME__, GIT_COMMIT); return buf; }编译时通过-DGIT_COMMIT$(git rev-parse --short HEAD)传入这样版本信息就非常完整了。6.3 避免在库中固化时间如果你在开发一个库尽量不要在库的代码里使用__DATE__和__TIME__因为库的编译时间和最终应用的编译时间可能不同。更好的做法是提供一个接口让应用层自己传入构建时间或者由应用层在启动时记录。库只负责提供功能不负责记录构建信息。6.4 用脚本自动生成版本文件对于大型项目手动维护版本文件容易出错。可以写一个脚本在构建前自动生成一个version.c里面包含__DATE__、__TIME__以及从 Git 获取的信息。这样每次构建都会重新生成确保时间是最新的。#!/bin/bash cat version.c EOF const char* build_date __DATE__; const char* build_time __TIME__; const char* git_commit $(git rev-parse --short HEAD); EOF然后在构建脚本里先执行这个脚本再编译。这样既保证了时间更新又避免了手动修改。7. 个人经验什么时候该用什么时候不该用用了这么多年我的体会是__DATE__和__TIME__适合做辅助性的版本标识但不适合做精确的时间记录。它们的精度只到秒而且受编译环境时区影响所以不要用它们来做时间计算或排序除非你先解析成标准时间格式。另外如果你的项目有严格的构建缓存策略使用这两个宏会破坏缓存导致构建变慢。这时候可以考虑用构建系统提供的版本注入机制比如 CMake 的configure_file在配置阶段生成版本文件而不是在编译阶段用宏。这样既能控制更新时间又不会影响所有文件的缓存。最后一个小技巧如果你只是想在调试时快速知道二进制是不是最新的可以在main函数开头打印一行构建时间然后和当前时间对比。如果构建时间是几分钟前说明是刚编译的如果是几天前说明可能用的是旧二进制。这个习惯帮我省了不少排查时间。注意__DATE__和__TIME__是编译期常量不是运行时变量。任何试图在运行时修改它们的做法都是无效的。理解这一点能帮你避开大部分相关的坑。