时间戳单位识别
Unix 时间戳的位数直接对应单位：10 位约为秒、13 位约为毫秒、16 位约为微秒、19 位约为纳秒。时序库、消息队列与客户端库的默认单位并不统一，因此写入端的单位声明与查询端的解析必须成对配置好，否则数据会落到几十年之外的时间点上。
位数与单位对照
| 位数 | 单位 | 示例 | 常见来源 |
|---|---|---|---|
| 10 位 | 秒 | 1719792000 | Unix 默认、ClickHouse DateTime、MySQL TIMESTAMP |
| 13 位 | 毫秒 | 1719792000000 | JavaScript Date.now()、Elasticsearch 默认 epoch_millis |
| 16 位 | 微秒 | 1719792000000000 | 部分数据库高精度时间类型 |
| 19 位 | 纳秒 | 1719792000000000000 | InfluxDB 默认精度、Go 的 time.UnixNano |
基本信息
| 写入侧声明 | InfluxDB 的 precision 参数可取 ns / us / ms / s |
|---|---|
| 查询侧转换 | 按实际单位除以对应倍数再格式化，别在查询里对毫秒值当秒用 |
| 存储精度 | ClickHouse DateTime 为秒级、DateTime64(3) 为毫秒级；ES date 可配置 format |
| 时区问题 | 时间戳本身是 UTC，展示时才做时区转换 |
| 换算工具 | date -d @1719792000、date +%s%3N 可快速互相验证 |
典型使用场景
- 排查写入后数据落在 1970 年：先确认写入精度参数与数据本身单位是否一致
- 跨语言数据管道：Go 与 JavaScript 默认精度不同，边界处显式转换最稳
- 图表时间轴错位：展示层把毫秒值乘以 1000 当纳秒渲染，会得到未来时间
- 对账时间窗口：两端单位不同时会算出空窗口，靠最小最大时间戳对齐验证
- 日志与指标关联：统一转换到毫秒再入库，便于跨系统按时间对齐
识别与换算
识别与换算
# 按数量级目测单位：10 位秒、13 位毫秒、19 位纳秒
# 1719792000 秒
# 1719792000000 毫秒
# 1719792000000000000 纳秒
# 写入时显式声明精度，避免服务端按默认纳秒解释毫秒值
gzip -c data.lp | curl -XPOST "http://127.0.0.1:8086/api/v2/write?org=my-org&bucket=metrics&precision=ms" \
-H "Authorization: Token $INFLUX_TOKEN" -H "Content-Encoding: gzip" --data-binary @-
# 本地快速换算与核对
date -d @1719792000 '+%F %T %Z' # 秒 -> 可读时间
date +%s%3N # 当前时间的毫秒值把单位约定写进数据管道文档：采集端统一输出毫秒、入库时显式声明、查询端按同一口径解析。事后从数据分布反推单位既慢又容易再次出错。
单位错误往往不会报错：数值是合法时间戳，只是落在错误的时间点，查询范围全空时第一时间检查这里。