I don't know the whole history behind this but I can think of the following reasons: * (Legacy) Instant class, et al., came with JDK 8 and Calcite code is much older than that * (Performance) Operations between longs are much more efficient than the respective ones with objects * (Code reuse) Code generation is easier when using primitive types
Best, Stamatis On Mon, Sep 5, 2022 at 11:41 AM Dmitry Sysolyatin <[email protected]> wrote: > I have created task - https://issues.apache.org/jira/browse/CALCITE-5266 > > On Sat, Sep 3, 2022 at 5:22 PM Dmitry Sysolyatin <[email protected]> > wrote: > > > Ok, I will create a task. > > Was there any reason why Long was chosen initially for representing > > TIMESTAMP instead of using java.time.Instant ? > > I propose to use standard java time classes: java.time.Instant for > > TIMESTAMP type and combination of java.time.Period and java.time.Duration > > for INTERVAL type. > > > > > > On Thu, Sep 1, 2022 at 7:58 PM Julian Hyde <[email protected]> > wrote: > > > >> I don’t think there’s a way to preserve microseconds and nanoseconds. > >> That would require more than 64 bits of numeric precision. > >> > >> Can you log a jira case for the feature that you think would fix this? I > >> think first we need a way to internally represent TIMESTAMP(n) for n > > 3. > >> Then we also need support for LocalDateTime in JDBC > >> (PreparedStatement.setObject, ResultSet.getObject, etc.) > >> > >> > On Sep 1, 2022, at 7:19 AM, Dmitry Sysolyatin < > [email protected]> > >> wrote: > >> > > >> > Hi! > >> > I have an issue with dynamic parameters. I tried to pass > >> > "java.time.LocalDateTime" value for TIMESTAMP dynamic parameter using > >> > DataContext and got an exception: > >> > > >> > "class java.time.LocalDateTime cannot be cast to class > java.lang.Long." > >> > > >> > I converted java.time.LocalDateTime to Long, but unfortunately, by > using > >> > Long, microseconds and nanoseconds were lost. > >> > > >> > Is there a way to preserve microseconds and nanoseconds ? > >> > >> >
