最直接、跨平台且符合现代c++标准的做法是用std::chrono::system_clock::to_time_t()转换为std::time_t,再转为秒数;它隐式处理utc,避免误用steady_clock或手动时区计算。

用 std::chrono::system_clock 获取秒级 Unix 时间戳
最直接、跨平台且符合现代 C++ 标准的做法是通过 std::chrono::system_clock 转换到 std::time_t,再转为秒数。它本质上就是 Unix Epoch(1970-01-01 00:00:00 UTC)以来的秒数。
常见错误是误用 std::chrono::steady_clock —— 它不关联系统时间,不能用于获取 Epoch 时间;还有人试图手动计算时区偏移,其实 system_clock::to_time_t 已隐式处理为 UTC。
-
std::time_t在绝大多数平台上就是秒级整数,直接赋值即可 - 注意:C++20 前,
system_clock::time_point的精度不保证是纳秒,但转time_t后一定是秒级 - 示例:
auto now = std::chrono::system_clock::now(); std::time_t t = std::chrono::system_clock::to_time_t(now); std::cout
需要毫秒或微秒级精度怎么办
如果业务要求更高精度(比如日志打点、性能测量),不能依赖 time_t,得从 system_clock::now() 提取原生 duration。
关键点在于:Unix Epoch 是一个时间点,精度取决于你如何表达它 —— 秒是约定,但毫秒/微秒同样合法,只是需明确单位。
- 用
std::chrono::duration_cast<:chrono::milliseconds>(now.time_since_epoch()).count()</:chrono::milliseconds>得到毫秒数 - 避免先转
time_t再乘 1000:会丢失 sub-second 部分,且引入浮点误差风险 - 不同平台下
system_clock的底层周期可能不同(如 Windows 常为 100ns,Linux 通常为 1ns),但duration_cast会安全截断或舍入
在 C++11 之前或嵌入式环境没 std::chrono 怎么办
老项目或受限环境可能只能用 C 标准库,此时 std::time(nullptr) 是最稳妥选择,它等价于 time(NULL),返回的就是 Unix 秒数。
容易踩的坑是传入未初始化的指针,或误以为它返回的是本地时间 —— 实际上它返回 UTC 时间对应的 time_t,和 Unix Epoch 定义一致。
- 不要用
localtime或strftime反推,徒增复杂度且易出错 - 若需兼容 C++98,这是唯一可移植方案
- 示例:
std::time_t t = std::time(nullptr); // 注意 nullptr,不是 0(虽多数实现兼容,但标准要求指针)
为什么 gettimeofday() 不推荐
虽然 POSIX 的 gettimeofday() 能返回微秒级时间,但它已被标记为 legacy,C++ 标准不保证其可用性,且在 macOS 和部分嵌入式 libc 中已被弃用或移除。
更严重的问题是语义混淆:它的 struct timeval 中的 tv_sec 是 Unix 秒,但很多人忽略 tv_usec 是微秒而非毫秒,导致单位换算错误。
- C++20 引入了
std::chrono::utc_clock,但目前主流编译器支持有限,暂不建议生产环境依赖 - Windows 上若用
GetSystemTimeAsFileTime,需手动减去 Windows Epoch(1601-01-01)偏移,容易算错常量 - 结论:除非明确要求兼容极老系统且已验证
gettimeofday存在,否则一律优先走std::chrono::system_clock
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











