Vlad Ilyushchenko

thanks, we use an implementation of https://www.researchgate.net/publication/2295884_How_to_Read_Floating_Point_Numbers_Accurately For more context the issue is with string-to-double conversion, for this: ```java System.out.println(Double.parseDouble("1.718500000000000139")); System.out.println(Double.parseDouble("-1.718499999999999917")); System.out.println(Numbers.parseDouble("1.718500000000000139")); System.out.println(Numbers.parseDouble("-1.718499999999999917")); ``` produces: ``` 1.7185000000000001 -1.7185 1.7185000000000004 -1.7185...

as a side note, we'd like to converge on binary data transfer quite soon

this could be a `feat`

We are actively working on this in-house

It is being worked on

- you can use docker image from dockerhub, it is fixed - try pruning docker caches and restarting build

Can I close the issue now?

QuestDB doesn't have timestamp_with_timezone datatype, so that to_timezone() return value is interpreted as TIMESTAMP (always UTC). While I fully agree this is confusing, what are the practical implications of this?...

Perhaps we can return make return value of `to_timezone()` a `string` ?

@jerrinot This test does NOT fail on master ```java @Test public void testNegative() { int key = 1; IntObjHashMap map = new IntObjHashMap(); map.put(key, "foo"); Assert.assertEquals("foo", map.get(key)); } ```