Calcite doesn’t use java.sql.Time internally to represent values of SQL type TIME (except when you read them using JDBC). It uses int.
Suppose we wanted to support TIME values to attosecond (10^-18 second) precision. We could process values in any type that can hold integers with 24 decimal digits (there are 86,400 seconds in a day, which is 8 * 10^23 attoseconds). So basically we need an efficient implementation of numbers with an arbitrary (but fixed) decimal precision. We would also have to provide a way to get arbitrary precision values from JDBC. Rather than calling ResultSet.getTime(), people could get the values by calling ResultSet.getObject() to return a BigDecimal value, or by calling ResultSet.getString(). Julian > On Aug 11, 2023, at 3:09 PM, Mihai Budiu <[email protected]> wrote: > > 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 >>
