In compilers it is a best practice to represent literals using exact, unbounded precision values. In Calcite we use BigDecimal for numbers and TimeString (TimestampString, DateString) for date and time literals.
At runtime there are different considerations. We need a representation that is space and time efficient, and therefore will choose something like a 64 bit signed integer for timestamp values, which gives us millisecond precision over a reasonable range of dates. (No primitive Java data type stores more than 64 bits.) If we are bounded by 64 bits, then extending the precision to microseconds or nanoseconds or beyond will cause us to have to cover a smaller range of dates. If we want unlimited precision over a reasonable range, we have to use a representation, analogous to BigDecimal, that stores values on the Java heap. It would be nice if people could choose an alternative runtime representation of date-time values. I would welcome such a contribution. Julian On Aug 11, 2023, at 00:54, Stamatis Zampetakis <[email protected]> wrote: Hey Mihai, I'm not sure to which part of calcite you refer to by saying that it supports arbitrary precision strings but it is not uncommon for consumers to use only a single component from calcite (say the parser) so I wouldn't be surprised if there are implementation gaps in other places. Best, Stamatis On Fri, Aug 11, 2023, 3:07 AM <[email protected]> wrote: Why does Calcite support arbitrary precision time-strings and yet makes it practically impossible to extract anything but milliseconds? Mihai
