C++如何格式化日期字符串

C++日期格式化：别让"YYYY-MM-DD"绊倒你

日期格式化这事，说起来简单，C++里却藏着不少坑。从C++11到C++20，可用的工具越来越多，但选择哪种方案、怎么避开常见陷阱，才是真正需要花心思的地方。

用 std::format（C++20）直接格式化日期

如果你的编译器已经支持C++20的std::format（GCC 13+、Clang 15+、MSVC 19.30+都可以），这无疑是最干净的写法。它原生支持std::chrono::system_clock::time_point和std::chrono::year_month_day这类类型，省去了不少转换步骤。

最容易掉进的坑是什么？直接拿raw time_t或struct tm往里塞——std::format根本不认这个，必须先转成标准chrono类型。

• 先用std::chrono::system_clock::now()拿到时间点，再用std::chrono::floor截断纳秒，否则格式化时会冒出小数秒
• 格式字符串用{:%Y-%m-%d %H:%M:%S}，这里的%转义符和printf风格一致，但注意只支持ISO 8601相关字段（%Z、%z在部分标准库中仍不可用）
• 示例：

  auto now = std::chrono::floor(std::chrono::system_clock::now());
  std::string s = std::format("{:%Y-%m-%d %H:%M:%S}", now);

用 std::put_time（C++11）配合 std::localtime / std::gmtime

这是兼容性最广的方案，所有支持C++11的标准库都能用。但线程安全和时区陷阱，一个都不能忽视。

这里有个典型问题：直接对std::time(nullptr)返回的time_t调用std::localtime，返回的指针指向静态缓冲区——后续调用会把它覆盖掉。多线程下更是灾难。

• 务必用std::localtime_r（POSIX）或std::localtime_s（Windows）替代std::localtime，确保线程安全
• 如果需要UTC时间，用std::gmtime_r / std::gmtime_s，别指望std::put_time自动识别时区
• 示例（POSIX）：

  std::time_t t = std::time(nullptr);
  struct tm buf{};
  std::localtime_r(&t, &buf);
  std::ostringstream oss;
  oss << std::put_time(&buf, "%Y-%m-%d %H:%M:%S");
  std::string s = oss.str();

跨平台封装时避开 strftime 的 locale 依赖

strftime看起来简单，但有个隐藏陷阱：它默认受当前locale影响。比如在中文locale下，%B输出的是"十二月"而不是"December"。很多服务端程序因此出现日志乱码或解析失败。

除非你明确需要本地化名称（比如UI层），否则应该强制设为"C" locale来保证可移植性。

• 调用前执行std::setlocale(LC_TIME, "C")，但注意这个函数不是线程安全的
• 更稳妥的做法是用std::locale::global(std::locale("C"))（影响整个程序），或者在格式化前临时切换locale并恢复
• 如果只处理数字型字段（%Y、%m、%d），其实不受locale影响，可以跳过这步

第三方库选 date.h 还是 fmt？

Howard Hinnant的date.h（已并入C++20 ）和fmt库都提供更灵活的日期格式化能力，但引入方式不同。

容易踩的坑是：以为fmt::format支持所有strftime格式符——实际上它只支持子集，而且对std::chrono::zoned_time等高级类型的支持依赖编译选项（如FMT_LOCALE）。

• date.h更专注时间，适合需要时区、历法计算的场景，但头文件较大、编译慢
• fmt更通用，如果项目已经用它做字符串格式化，复用fmt::format可以减少依赖，但需要确认版本（≥10.0才完整支持chrono格式化）
• 两者都不修改全局locale，规避了std::put_time的隐式依赖问题

真正麻烦的从来不是"怎么拼出YYYY-MM-DD"，而是时区、线程安全、locale和跨平台行为的一致性。哪怕只用std::put_time，也得盯住那个_r或_s后缀。