-
Notifications
You must be signed in to change notification settings - Fork 479
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 is serialized not consistently in MsgPack and Json, missing millis and nanos in MsgPack #517
Comments
Hi @rhajek ,
JSON parser have no idea if a string representation of a number is encoding an integer or a floating point value (However MessagePack does since MessagePack encodes type of value element as well). So most of JSON parsers (I know at least Moshi and Jackson) decide to decode number as double value by default (I see from Moshi 1.6 we can have custom adapter but I haven't tried it)
Not only MsgPack, there is already an open issue for this (issue #491) |
If the EPOCH is specified in query, MsgPack timestamp is encoded to long correctly.
client.query(Query) without EPOCH should also always return time in RFC (with nanosecods, if they are written in DB) Server sends timestamp encoded in MspPack EXTENSION type, but it looks like miliseconds and nonos are lost... I am not sure if the problem is in java msgpack library on or on server side. case EXTENSION:
final byte msgPackTimeExtType = (byte) 5;
final int timeOffset = 0;
final int timeByteArrayLength = 8;
extension = unpacker.unpackExtensionTypeHeader();
if (extension.getType() == msgPackTimeExtType) {
dst = new byte[extension.getLength()];
unpacker.readPayload(dst);
o = ByteBuffer.wrap(dst, timeOffset, extension.getLength()).getLong(); ## <- milis/nanos are not here |
Not sure if I am fully understand you last comment Time is encoded in 12 bytes so maybe what you need is lying in the remaining 4 byte ? |
fix issue #517 : missing millis and nanos in MsgPack
It is not possible to simply switch json and mspack response encoding implementation. Json (Mochi) serializes time as a String in RFC but MsgPack encodes time into Long. Miliseconds/Nanoseconds are lost in the case of MessagePack. It looks like bug in MsgPack encoder on server side .
If the EPOCH param is specified in query, ex. client.query(query,TimeUnit.NANOSECONDS) then json encodes time as Double (why not long?) and MsgPack as a Long (that looks ok).
Another issue is that there is no way how to get time with milis/nanos precission with async streaming in MsgPack. There is no async API with EPOCH parameter.
Here is failing test:
The text was updated successfully, but these errors were encountered: