mysql timestamp 应映射为 std::chrono::system_clock::time_point 最稳妥，因其存储为 utc；解析时需先设连接时区为 '+00:00'，用 std::get_time 解析字符串后调用 timegm（linux/macos）或 _mkgmtime（windows）转 time_t，再通过 from_time_t 构造 time_point 并加上微秒偏移。
MySQL 的 TIMESTAMP 怎么映射到 C++ 类型？
直接映射成 std::time_t 或 std::chrono::system_clock::time_point 最稳妥，但要注意 MySQL 的 TIMESTAMP 是带时区的（存储为 UTC，检索时按连接时区转换），而 C++ 标准库本身不带时区语义。如果你用的是 DATE 或 DATETIME，那就纯本地时间，更简单些。
常见错误是把 TIMESTAMP 当作本地时间硬塞进 struct tm 再用 mktime 转——这会因本地时区偏移错乱几小时。正确做法是：先让 MySQL 返回 UTC 时间字符串（比如 "2024-05-12 08:30:45"），再用 std::get_time 解析为 std::tm，然后调用 timegm（不是 mktime）转成 time_t。
- 使用
timegm前需定义_GNU_SOURCE（Linux）或确保 glibc 版本支持；macOS 用timegm，Windows 用_mkgmtime - 如果用
mysqlpp::DateTime或soci::date等封装类，它们内部通常已处理时区逻辑，但务必查文档确认是否默认返回 UTC - 避免用
std::stoi拆分字符串年月日——精度丢失、无闰秒容错、不处理微秒
从 MySQL C API 读取 TIMESTAMP 字段的实际步骤
MySQL C API 返回的是 MYSQL_TIME 结构体，它本身不含时区信息，值取决于当前连接的 time_zone 设置。所以不能直接信任它的 year/month/day/hour 字段是 UTC 还是本地时间。
更可靠的做法是：在执行查询前，显式设置连接时区为 UTC：SET time_zone = '+00:00'，再用 mysql_fetch_row + mysql_fetch_lengths 获取原始字符串值（如 "2024-05-12 08:30:45" 或 "2024-05-12 08:30:45.123456"），再解析。
- 用
std::istringstream+std::get_time解析到std::tm，注意格式字符串要匹配（"%Y-%m-%d %H:%M:%S"或加%.f处理微秒） - 微秒部分需单独提取：用
strchr找小数点，再用std::stoi读后面最多 6 位数字，补零到 6 位后构造std::chrono::microseconds - 别依赖
mysql_field_type判断是不是TIMESTAMP——它返回的是MYSQL_TYPE_TIMESTAMP，但字段实际可能是DATETIME，类型名和语义容易混淆
用 std::chrono 构造带微秒精度的 time_point
MySQL 5.6.4+ 支持 TIMESTAMP(6)，C++ 里要用 std::chrono::system_clock::time_point 存，但它的底层时钟精度不一定等于微秒（system_clock::period 通常是纳秒或微秒，依平台而定）。关键不是“能不能存”，而是“怎么从字符串精确还原”。
推荐组合：用 timegm 得到秒级 time_t，再用 std::chrono::seconds 构造基础 time_point，最后加上微秒偏移。
std::string s = "2024-05-12 08:30:45.123456";
std::tm tm = {};
std::istringstream ss(s.substr(0, 19)); // 先截出 "YYYY-MM-DD HH:MM:SS"
ss >> std::get_time(&tm, "%Y-%m-%d %H:%M:%S");
auto sec_tp = std::chrono::system_clock::from_time_t(timegm(&tm));
int micros = std::stoi(s.substr(20)); // 提取小数点后内容
auto full_tp = sec_tp + std::chrono::microseconds(micros);
-
timegm不修改tm.tm_isdst，所以不用管夏令时 - 如果字符串只有毫秒（3 位），
std::stoi会自动截断，但建议统一补零到 6 位再转，避免误判 - 不要用
std::chrono::high_resolution_clock替代system_clock——它不保证对应 Unix 时间戳，无法和数据库对齐
ODBC 或 ORM（如 SOCI、SQLiteCpp）里怎么避免时区陷阱？
ODBC 驱动默认把 TIMESTAMP 映射为 SQL_TIMESTAMP，但驱动行为不统一：MySQL ODBC 把它当本地时间处理，PostgreSQL ODBC 默认返回 UTC。SOCI 的 use/into 绑定 soci::timestamp 时，底层仍依赖驱动返回的 SQL_TIMESTAMP_STRUCT，而这个结构体的 fraction 字段单位是纳秒，但 MySQL 不填它——导致微秒丢失。
最可控的方式是：绕过 ORM 的时间类型绑定，改用字符串读取，再自己解析。例如 SOCI 中写 row ，然后手动 parse。
- SQLite 没有原生
TIMESTAMP，通常存为 TEXT（ISO8601）或 INTEGER（Unix 时间戳），反而更干净，直接用std::stoll或std::get_time即可 - 如果必须用 ORM 的时间类型，务必测试跨时区场景：在东八区机器连 UTC 时区的 MySQL，插入后立刻查，看值是否偏移 8 小时
- 所有日志、调试输出时间值时，强制打印为 UTC 字符串（
std::put_time(&gmtime(...), "...")），别依赖ctime或本地格式化
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
