I have created task - https://issues.apache.org/jira/browse/CALCITE-5266
On Sat, Sep 3, 2022 at 5:22 PM Dmitry Sysolyatin <dm.sysolya...@gmail.com> 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 <jhyde.apa...@gmail.com> 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 <dm.sysolya...@gmail.com> >> 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 ? >> >>
