C++里time_get不是“时间获取器”，它是时间格式的翻译官

你有没有试过用std::get_time读取用户输入的日期，结果一输“2024-03-15”就崩？或者明明写了%Y-%m-%d，却对“15/03/2024”束手无策？别急着骂C++标准库难用——问题往往不在get_time本身，而在它背后那个沉默的搭档：std::time_get。

它不负责“获取”时间，也不解析字符串；它只做一件事：把符合当前locale规则的文本片段，映射成std::tm结构里的对应字段。换句话说，它是时间格式的“本地化翻译官”，而翻译质量，全看locale给它配了哪本词典。

time_get是std::time_get_byname和std::time_get<char>等facet的统称，藏在<locale>头文件里，通常不直接调用。你真正打交道的是std::get_time这个流操纵器——它内部会悄悄调用当前imbue进流的locale所携带的time_get facet。

所以，第一关永远是locale。
默认全局locale（""）在不同系统表现差异极大：Linux下常是C locale，只认%H:%M:%S这类POSIX格式；Windows控制台则可能用系统区域设置，但又未必和你的终端编码一致。不显式指定locale，等于让翻译官蒙着眼干活。

比如这段代码：

std::istringstream ss("15/03/2024");
std::tm t{};
ss >> std::get_time(&t, "%d/%m/%Y");

在多数Linux环境下会失败——因为C locale的time_get根本不认识%d/%m/%Y这种欧洲写法。它只接受%m/%d/%Y（美式），或更保守的%Y-%m-%d。

解法不是换格式，而是换“词典”：

std::locale uk_loc("en_GB.UTF-8");  // 或 "English_United Kingdom"
ss.imbue(uk_loc);
ss >> std::get_time(&t, "%d/%m/%Y"); // ✅ 成功

注意："en_GB.UTF-8"必须真实存在于你的系统中（Linux/macOS可用locale -a | grep en_GB确认）。Windows上得用"English_United Kingdom.1252"这类名称，且需确保系统已安装对应语言包。locale名称不是随便写的字符串，而是操作系统级配置项。

time_get真正发力的地方，在于它处理“模糊输入”的逻辑。比如用户输入"Mar 2024"，没有日，time_get不会报错，而是保持tm_mday为0（即未设置），同时正确填入tm_mon=2、tm_year=124（注意：tm_year是距1900年的年数）。这和strptime的“未指定字段留原值”行为一致，但很多开发者误以为它会自动补1号——不会。tm_mday仍为0，后续调用mktime前必须手动设为1，否则结果不可预测。

再比如星期缩写："Mon"在en_US下能识别，但在de_DE下得写"Mo"。time_get严格按locale的_M_weekday数组匹配，不搞智能容错。它不猜意图，只查表。

一个容易被忽略的细节：time_get::do_get的返回值是std::ios_base::iostate。std::get_time内部会检查这个状态，但错误信息完全不反馈给用户——流仅置failbit，你得自己用ss.fail()判断，再结合ss.tellg()定位到哪一字符卡住。调试时建议先用ss.str()打印原始输入，再对照locale支持的格式逐字比对。

还有个实用技巧：若需混合解析（如“2024-03-15T14:30:00+0800”），别硬塞进单个get_time。拆成两步更稳：先用"%Y-%m-%d"读日期，再用"T%H:%M:%S%z"读剩余部分。time_get对连续格式的支持有限，强行拼长格式反而易出错。

最后说句实在话：time_get不是为日常开发设计的“便利工具”，它是C++标准为国际化场景预留的底层接口。如果你只是解析固定格式的API响应，用std::chrono::parse（C++20）或轻量正则更直接；但当你面对多语言用户输入、需要和系统时区/本地习惯深度耦合时，time_get的价值才真正浮现——它让程序能听懂巴黎人写的“15 mars 2024”，也能理解东京人写的“2024年3月15日”。

它的存在意义，从来不是简化时间解析，而是尊重时间表达背后的地域逻辑。

下次看到get_time失效，先别改代码，打开终端敲locale，看看你的翻译官今天带的是哪本词典。