In this question I was referring to the TimeString class in particular. Related to this, I have filed an issue with the compile-time evaluation of Time expressions: https://issues.apache.org/jira/browse/CALCITE-5919
Unfortunately it looks like in the Java type system Time values are represented using int and not long. This is a big problem, since it precludes using high precision time values. Mihai On Fri, Aug 11, 2023 at 2:50 PM Julian Hyde <[email protected]> wrote: > 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 >
