RFC3339 解析

接口把时间写成 2026-11-11T10:20:30.123456789+08:00 时，我通常不会先把它拆成字符串再自己拼回时间。Go 的 time.Parse 已经能识别 RFC3339 形式，配合 time.RFC3339Nano 可以把秒后的可用小数秒交给 time.Time 保存。真正需要留意的是：保存下来的上限是纳秒，输出时 RFC3339 与 RFC3339Nano 的文本形态也不同。

官方文档：https://pkg.go.dev/time

解析带小数秒的 RFC3339 文本时，用 time.Parse(time.RFC3339Nano, value)，成功后通过 Nanosecond() 读取纳秒部分；超过 9 位的小数不能继续保留，格式化时若需要去掉末尾零再选 RFC3339Nano。

先分清布局常量和时间值

time.RFC3339 和 time.RFC3339Nano 都是布局字符串。前者的核心形态是 2006-01-02T15:04:05Z07:00，后者在秒后放入最多 9 位小数的示意布局。它们描述的是“输入或输出应该长什么样”，真正承载解析结果的是 time.Time。

这一区分很重要：调用 Parse 时，布局是规则；调用 Nanosecond() 时，读取的是解析后时间值里的纳秒部分。不要把布局常量当成精度开关，也不要因为变量名里有 Nano 就认为它能保存超过纳秒的原始文本。

为什么 RFC3339Nano 能接住小数秒

RFC3339 文本的秒字段后面可以紧跟小数部分。Go 的 time.Parse 在解析时允许这里出现小数点或逗号，随后读取连续数字；即使布局没有显式写出小数部分，解析器也会处理这一段。使用 RFC3339Nano 作为布局，可以把意图表达得更直接。

package main

import (
	"fmt"
	"time"
)

func main() {
	value := "2026-11-11T10:20:30.123456789+08:00"
	parsed, err := time.Parse(time.RFC3339Nano, value)
	if err != nil {
		// 输入格式或时区不符合布局时，不能把零值当成解析成功。
		fmt.Println("解析失败:", err)
		return
	}

	// Nanosecond 返回进入 time.Time 后的秒内纳秒部分。
	fmt.Println(parsed.Format(time.RFC3339Nano))
	fmt.Println(parsed.Nanosecond())
}

这里的 parsed 包含日期、时钟时间、时区偏移和纳秒字段。Nanosecond() 返回的是当前秒内的纳秒数，例如输入中的 9 位小数会对应一个 0 到 999999999 之间的整数。需要完整瞬时时，再结合 Unix() 或直接使用 time.Time，不要只保存这个纳秒字段。

解析成功不等于原文每一位都被保存

time.Time 的小数秒精度是纳秒。输入的小数位少于 9 位时，解析结果会按纳秒位置补足；输入多于 9 位时，超出的部分会被截断到纳秒精度。也就是说，解析后可以可靠地得到一个时间值，但不能再从 time.Time 反推出被截掉的第 10 位及之后的原始字符。

格式化时 RFC3339 和 RFC3339Nano 有什么差别

解析和格式化是两个方向。解析时，Go 会把小数秒放进 time.Time；格式化时，布局决定输出文本。RFC3339 适合固定到秒的标准形态，而 RFC3339Nano 会根据纳秒值输出小数，并删除小数末尾多余的零。

package main

import (
	"fmt"
	"time"
)

func main() {
	value := "2026-11-11T10:20:30.120000000Z"
	parsed, err := time.Parse(time.RFC3339Nano, value)
	if err != nil {
		// 解析错误要在格式化之前处理，避免把无效输入伪装成合法时间。
		fmt.Println("解析失败:", err)
		return
	}

	// RFC3339 固定输出到秒；RFC3339Nano 按纳秒值保留必要的小数位。
	fmt.Println("RFC3339:", parsed.Format(time.RFC3339))
	fmt.Println("RFC3339Nano:", parsed.Format(time.RFC3339Nano))
}

因此，不能把 Format(time.RFC3339Nano) 的结果当作原始字符串的逐字符副本。它是同一个时间值的规范化表达，可能和输入使用不同的时区写法，也可能因为去掉末尾零而变短。若日志或签名协议要求保留原始文本，应在解析前单独保存 value。

时区和错误分支要一起处理

带 Z 的输入表示 UTC，带 +08:00 之类偏移的输入则携带数值时区。解析成功后，比较时间点通常应使用 Equal，不要直接用字符串比较；两个不同偏移的字符串可能指向同一瞬间。另一方面，闰秒 60 不能被 time.Time 表示，日期、时分秒或时区格式不对也会返回错误。

func parseRFC3339(value string) (time.Time, error) {
	parsed, err := time.Parse(time.RFC3339Nano, value)
	if err != nil {
		// 把原始输入包含在上层错误上下文中，便于定位是哪条消息有问题。
		return time.Time{}, fmt.Errorf("解析 RFC3339 时间 %q: %w", value, err)
	}
	return parsed, nil
}

这个小函数的边界很窄：它负责把格式错误交给调用方，不负责猜测缺失时区、自动修正非法日期或把超高精度文本当成精确值。业务层如果需要保留原文，可以把 value 与返回的 time.Time 放在同一个结构中。

实际使用时记住这几条

• 读取 RFC3339 时间并保留小数秒：优先使用 time.Parse(time.RFC3339Nano, value)。
• 检查小数秒是否进入时间值：读取 parsed.Nanosecond()。
• 输入超过 9 位小数：接受纳秒截断，或额外保存原文。
• 需要可读输出：根据协议选择 RFC3339 或 RFC3339Nano，不要默认两者文本相同。
• 需要比较瞬间：使用 time.Time.Equal，不要依赖带时区字符串的字面顺序。

相关问题

RFC3339 和 RFC3339Nano 解析结果是两种类型吗？

不是。两者都是布局字符串，解析结果都是 time.Time；差别主要是布局表达和格式化时的小数秒输出。

为什么格式化后小数位变少了？

RFC3339Nano 会去掉秒后多余的尾随零，这是它的输出特性，不代表时间值丢失了纳秒字段。

超过 9 位小数还能无损解析吗？

不能无损存入 time.Time。Go 会把小数秒截断到纳秒精度；若原始文本有审计或签名价值，需要另存字符串。