Note that that function is for a specialized purpose: converting internal
timestamps to java.sql.Timestamp objects to be passed as arguments to
user-defined functions implemented in Java.
It assumes that the SQL timestamp values are in the JVM’s default time zone,
and since are converting to java.sql.Timestamp values, which are always
relative to UTC epoch, we need to subtract the local timezone offset.
(In other cases (e.g. sending values into or out of JDBC) we know that the
values are milliseconds since epoch, but we let the caller tell us what
timezone they think the timestamp values are in. Then we convert to a
java.sql.Timestamp which is always relative to the UTC epoch.)
Julian
> On Jul 19, 2019, at 1:33 PM, Shuyi Chen <suez1...@gmail.com> wrote:
>
> Hi all,
>
> I have a question regarding the usage & implementation of SqlFunctions.
> internalToTimestamp(long v) (I copied the implementation below). I want to
> clarify the definition of input parameter v. Is it milliseconds since
> epoch, or something else?
>
> If it is milliseconds since epoch, why do we need to minus it with LOCAL_TZ
> .getOffset(v)before passing it to the sql.Timestamp constructor. As
> documented in the sql.Timestamp constructor, the constructor also takes
> milliseconds since epoch. So it seems to me that the current implementation
> is wrong unless I misunderstood the definition of input parameter v or I
> don't have enough context. I am also happy to fix it or improve it if it's
> a bug. Thanks a lot.
>
> public static java.sql.Timestamp internalToTimestamp(long v) {
> return new java.sql.Timestamp(v - LOCAL_TZ.getOffset(v));
> }
>
>
> Shuyi
