Use int64 for API timestamp

[G10h4ck]

Address #345

[G10h4ck]

Seems we have similar but unrelated problem in ipfsync too https://github.com/vocdoni/vocdoni-node/blob/master/ipfssync/ipfssync.go#L40 @altergui I guess that should be treated separately

[altergui]

Seems we have similar but unrelated problem in ipfsync too https://github.com/vocdoni/vocdoni-node/blob/master/ipfssync/ipfssync.go#L40 @altergui I guess that should be treated separately

right, but in ipfssync, AFAIU, there's no api involved, the messages are only passed between ipfssync instances. so maybe it's a non-issue?

[G10h4ck]

right, but in ipfssync, AFAIU, there's no api involved, the messages are only passed between ipfssync instances. so maybe it's a non-issue?

If you plan to make it obsolete before 2037 no problem ;)

[jordipainan]

LGTM

@marcvelmer @brickpop @emmdim I think this also affects other repos can we sync on this ?

[G10h4ck]

I have made a PR for dvote-js too vocdoni/dvote-js#99

[NateWilliams2]

@G10h4ck Why are you using the json string tag for these fields? Is it needed?
I'm getting an error: getInfo: json: invalid use of ,string struct tag, trying to unmarshal unquoted value into int64

[G10h4ck]

@G10h4ck Why are you using the json string tag for these fields? Is it needed? I'm getting an error: getInfo: json: invalid use of ,string struct tag, trying to unmarshal unquoted value into int64

Are you getting that error attempting to parse a JSON generated by older version with the new one?
Using string representation for 64 bit integers is necessary to make it properly parse-able by clients that doesn't natively supports 64 bit integers natively such as Javascript and Dart

[p4u]

Jumping in without full context. As @G10h4ck states in the issue, there could be a precission problem if using int64 when interacting with JS libraries, please do not merge this until we are sure we won't have interoperability problems: @mvdan @brickpop @marcvelmer ?

In the worst case we can let it unmerged since the RPC API will require a full refactor in some moment.

[mvdan]

I thought we were fine with this small API breaking change, given that we can update the clients too at the same time. If we want the transition to be smoother, the server could accept both forms when decoding by implementing json.Unmarshaler. I can help with that if it sounds useful. We would still always encode as a string in the new version, so this would only help with older requests that didn't use strings, it won't help with clients that expect non-string responses.