CA-430573: Use int64 in Go SDK - #7232
Conversation
|
SDK test pass on XenRT job 4718034, 4718035. |
cb43a3f to
7c325ed
Compare
| return | ||
| } | ||
| strValue := fmt.Sprintf("%v", input) | ||
| floatValue, err := strconv.ParseFloat(strValue, 64) |
There was a problem hiding this comment.
Since we want an int64 in line 55, should we have first tried to use ParseInt here and then ParseFloat only if the former fails?
There was a problem hiding this comment.
Yes, good point, let me update.
There was a problem hiding this comment.
I think it again, here the input is the data time, like :
"20220101T123045"
"20220101T123045Z"
"20220101T123045+03"
"20220101T123045+0300"
"20220101T123045+03:00"
"20220101T123045.123"
"20220101T123045.123Z"
"20220101T123045.123+03
"20220101T123045.123+0300"
"20220101T123045.123+03:00"
"20220101T12:30:45"
"20220101T12:30:45Z"
"20220101T12:30:45+03"
"20220101T12:30:45+0300"
"20220101T12:30:45+03:00"
...
so mostly the value is parse by value, err = time.Parse(timeFormat, strValue).
The epoch value is int64-valued, but it never arrives as a parseable integer string. Over JSON-RPC, a JSON number decodes to Go float64 (Go's encoding/json always uses float64 for numbers into interface{}.) ParseInt can't read "1.7e+09", so ParseFloat is the correct primary parser and the separate int parse adds nothing.
So I prefer to keep the origin changes.
bcd6f8e to
0f40e47
Compare
Signed-off-by: Sola.Zhang <Sola.Zhang@cloud.com>
0f40e47 to
63e63d3
Compare
2 participants
No description provided.