Python 时间戳与纳秒精度的存储选择

应存入数据库的integer/bigint字段，因time.time_ns()返回19位纳秒整数，用浮点类型会丢失精度；解析时须先转秒级再处理纳秒部分，避免直接用fromtimestamp()导致溢出或截断。

python time.time_ns() 返回的值怎么存进数据库

直接存进 Integer 字段最稳妥。它返回的是自 unix 纪元起的纳秒整数，典型值像 1717023456123456789（19 位），mysql/postgresql/sqlite 的 BIGINT 或 INTEGER 都能装下。

别用 Float 或 double 存——浮点数在 10¹⁵ 以上就开始丢精度，纳秒级时间戳一存就偏几毫秒甚至更多。

• PostgreSQL：用 BIGINT，不是 NUMERIC，后者虽准但慢、占空间
• MySQL：用 BIGINT SIGNED，UNSIGNED 虽然能多存几年，但 Python 的 time.time_ns() 永远是正数，没必要徒增迁移风险
• SQLite：用 INTEGER，它本来就是 64 位有符号整型，完全匹配

用 datetime.fromtimestamp() 解析纳秒时间戳会出错

因为 datetime.fromtimestamp() 只接受秒级或最多微秒级浮点数，传入纳秒整数会报 OverflowError: timestamp out of range for platform time_t 或静默截断成错误时间。

正确做法是先除以 1_000_000_000 转成秒级浮点（保留小数），再传给 fromtimestamp()；或者更推荐——用整数除法和取模拆出秒+纳秒，再用 datetime.fromtimestamp(ts_sec, tz=timezone.utc).replace(microsecond=ts_ns % 1_000_000 // 1000) 手动拼，避免浮点误差。

立即学习“Python免费学习笔记（深入）”；

• 别写 datetime.fromtimestamp(ns_ts / 1e9)：1e9 是 float，除法结果仍是 float，仍有精度风险
• 如果只要 UTC 时间且不关心本地时区，优先用 datetime.utcfromtimestamp(ns_ts // 1_000_000_000) + 手动补纳秒部分到 microsecond 字段（注意纳秒转微秒要整除 1000）
• 用 time_ns() 记录的时间，本身不含时区信息，解析时别默认当成本地时间

SQLite 中用 strftime() 查纳秒时间戳很麻烦

SQLite 的 strftime() 函数只支持秒级时间，没有纳秒参数。直接对纳秒整数调用 strftime('%Y-%m-%d', ns_ts) 会当成“秒”处理，结果比真实时间早 10⁹ 倍——也就是回到公元前。

必须先换算：strftime('%Y-%m-%d', ns_ts / 1000000000, 'unixepoch')，而且得确保除法结果是浮点数（SQLite 会自动做类型推导，但显式写 1000000000.0 更稳）。

• WHERE 条件里比较纳秒时间戳，别写 ns_ts > strftime('%s', '2024-01-01')：这是把字符串转成秒再当纳秒用，逻辑全反了
• 想查“今天之后”的记录，得写 ns_ts > (strftime('%s', 'now') * 1000000000)
• 如果频繁按日期范围查询，考虑额外加一个 date_day INTEGER 字段存 ns_ts // 86400000000000（当天 0 点纳秒），用整数索引加速

Pydantic v2 模型里字段类型选 int 还是 conint

存纳秒时间戳就用原生 int。Pydantic v2 对 int 的校验足够强，能拦住 float、str、None 等非法输入，而 conint(ge=0) 只是多一层冗余检查，还可能掩盖真正的问题——比如上游传了个超大负数，你本该报警，而不是让它静默变成 0。

• 别用 float 字段接 time.time_ns()：Pydantic 会尝试转换，但会丢失精度，且类型语义错误
• 如果字段可能为空，用 Optional[int]，别用 int | None（v2 不识别这种联合写法）
• 序列化输出时若需兼容前端 js 的 Date.now()（毫秒级），记得在 @field_serializer 里手动除以 1_000_000 并转 int，别依赖自动转换

纳秒时间戳看着只是多几个零，但每一步转换都卡在整数/浮点、秒/纳秒、本地/UTC 这三道缝里，漏掉任意一个，时间就悄悄漂移了。