Go doesn’t have a built-in constant for ISO 8601 parsing, but you can reliably parse timestamps like 2016-07-25T02:22:33+0000 using the custom layout "2006-01-02T15:04:05-0700".
go doesn’t have a built-in constant for iso 8601 parsing, but you can reliably parse timestamps like `2016-07-25t02:22:33+0000` using the custom layout `"2006-01-02t15:04:05-0700".
In Go, time parsing relies on reference layouts—not format strings—based on the fixed date Mon Jan 2 15:04:05 MST 2006, which corresponds to 2006-01-02T15:04:05-0700. This makes Go’s time formatting unique and precise.
For ISO 8601 timestamps returned by APIs like Facebook (e.g., 2016-07-25T02:22:33+0000), the correct layout is:
const iso8601Layout = "2006-01-02T15:04:05-0700"
t, err := time.Parse(iso8601Layout, "2016-07-25T02:22:33+0000")
if err != nil {
log.Fatal(err)
}
fmt.Println(t) // 2016-07-25 02:22:33 +0000 UTC⚠️ Important notes:
- This layout assumes no fractional seconds and no colon in the timezone offset (e.g., +0000, not +00:00). If your input includes milliseconds (2016-07-25T02:22:33.123+0000) or colon-separated offsets (+00:00), you’ll need extended layouts:
- With milliseconds: "2006-01-02T15:04:05.000-0700"
- With colon in timezone: "2006-01-02T15:04:05-07:00"
- Go’s time.RFC3339 layout ("2006-01-02T15:04:05Z07:00") handles +00:00-style offsets and optional nanoseconds—but it requires the Z suffix for UTC (e.g., ...Z) or colonated offsets. It won’t match +0000 directly.
✅ Best practice: Validate your API’s exact timestamp format first. For Facebook Graph API v10+, timestamps consistently use YYYY-MM-DDTHH:MM:SS±HHMM (no colon, no subseconds), so "2006-01-02T15:04:05-0700" is safe and idiomatic.
In summary: use "2006-01-02T15:04:05-0700" for standard Facebook-style ISO 8601 timestamps—and extend the layout only when your data deviates from that pattern.
