Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
time: RFC3339 time.Parse can not parse string that come from time.Format #20555
Please answer these questions before submitting your issue. Thanks!
What did you do?
What did you expect to see?
What did you see instead?
Because the RFC3339 parse/format is using in json.
This string is found by using https://github.com/dvyukov/go-fuzz
This is not a bug in the time package. It's true that you can format a time using
Can you express this as an issue about encoding/json?
"Can you express this as an issue about encoding/json?"
I assumes that I can json.Unmarshal A to B successfully,so I can json.Marshal B to C,and I can json.Unmarshal C to D successfully.
The RFC defines time-numoffset in terms of time-hour and time-minute which are limited to 0-24 and 0-59. From a quick look I can't see any checking on zone offsets (other fields are checked) in the source for the parse() function, could this be added? Otherwise should it just be noted in docs that zone offsets are not range checked?
This does seem rather theoretical as the offset is invalid (I think, unless I'm reading the RFC wrong), but it might be worth documenting or returning an out of range error.
I've just been hit by this issue.
I would expect
It seems rather inconsistent....
I would like to add my experience to this. Would really love to see a fix for this. Many systems (including fmt.Println(someTime) output the time as YYYY-MM-DDTHH:MM:SS.sss+HHMM (note no colon on offset).
The RFC 3339 spec notes that the colon is optional for the offset (see https://tools.ietf.org/html/rfc3339#appendix-A). Because the json.Unmarshal() automatically uses the RFC3339 as the format, this prevents Go from parsing many versions of the standard timestamp format in its acceptance of json.
All of these should be valid:
I'm wonder if supporting the colon in the offset being optional really requires waiting for Go 2?