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::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后缀。
