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