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 ? > >
