-
Notifications
You must be signed in to change notification settings - Fork 17.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
time: RFC3339 time.Parse can not parse string that come from time.Format #20555
Comments
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. []byte(`"0007-05-31T3:50:00+99:80"`) |
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. https://tools.ietf.org/html/rfc3339#section-5.6
|
I've just been hit by this issue. I would expect It seems rather inconsistent....
|
It seems that Parse and Format should be symmetric in their behavior. Marking for consideration in Go2 at least. |
Making them fully symmetric seems reasonable, but it also seems quite hard to do it in a backward compatible manner. And even if we want to automatically fix existing uses, it seems quite hard to do so with complete reliability. |
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? |
Just ran into issues parsing dates out of the Sonatype Nexus 3 API. This has been open for 697 days now, can we get this issue on a road map? |
I don't think we even know what should be done. You can not use |
Just ran into this as well trying to unmarshal a Bitbucket Webhook payload. |
I'm going to put out perhaps a somewhat unpopular opinion, but perhaps the designers of Golang and the core libs to re-assess whether the "by example" format string that Go uses is actually fit for purpose. I know we can have arguments about what is more 'understandable', and I don't contest that perhaps some people find this easier, and others find the approaches used in other languages (like C, Swift, Ruby etc). BUT, it seems that the Go approach just is not able to parse all scenarios using the Time functionality. It forces you to perform direct string parsing instead. |
As I said just a few posts up, I don't think we even know what should be done. I agree that while the format string works reasonably well for |
https://play.golang.org/p/hM_DWyv0JMK shows another issue, it appears that time.Parse can only handle 4 digit years for RFC3339. |
@brian-brazil I think that is behaviour as expected. RFC3339 assumes that:
|
https://play.golang.org/p/Dflk-FGvm40. But the timezone must be within 24 hours ideally |
https://play.golang.org/p/2xDQsXxYcxe Even the layout itself is not a valid value,
|
This comment has been minimized.
This comment has been minimized.
Experiencing this same issue trying to unmarshal json from firebase |
This comment has been minimized.
This comment has been minimized.
@thaney071 that is something else and documented:
|
@seankhliao That is unfortunate because it makes testing time structure difficult since any deep equals check of the time struct before and after the marshaling will not be equal. |
This is expected and documented: |
- Fixed a bug with timestamp processing in splunkpump due to an ongoing issue with go. See golang/go#20555 - Updated debugging with a technique for running stopped containers - Moved overview to images folder Signed-off-by: Grant Curell <grant_curell@dell.com>
- Fixed a bug with timestamp processing in splunkpump due to an ongoing issue with go. See golang/go#20555 - Updated debugging with a technique for running stopped containers - Moved overview to images folder Signed-off-by: Grant Curell <grant_curell@dell.com>
- Fixed a bug with timestamp processing in splunkpump due to an ongoing issue with go. See golang/go#20555 - Updated debugging with a technique for running stopped containers - Moved overview to images folder Signed-off-by: Grant Curell <grant_curell@dell.com>
- Fixed a bug with timestamp processing in splunkpump due to an ongoing issue with go. See golang/go#20555 - Updated debugging with a technique for running stopped containers - Moved overview to images folder Signed-off-by: Grant Curell <grant_curell@dell.com>
I'm closing this issue because there is nothing to be done at this point. This general idea can be revisited in the context of a time/v2 package. But that package would have many other differences with regard to formatting, and I don't think we are going to forget this issue. |
Please answer these questions before submitting your issue. Thanks!
What did you do?
ttps://play.golang.org/p/BItq172M-_
The bad time string "0007-05-31T3:50:00+99:80"
What did you expect to see?
What did you see instead?
Because the RFC3339 parse/format is using in json.
This may curse some crashes with special user input and developer assumes that json.Unmarshal is not return an error equals to json.Unmarshal/json.Marshal/json.Unmarshal will not return an error
This string is found by using https://github.com/dvyukov/go-fuzz
The text was updated successfully, but these errors were encountered: