[
https://issues.apache.org/jira/browse/CALCITE-6896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17936407#comment-17936407
]
Julian Hyde commented on CALCITE-6896:
--------------------------------------
I would like to see a SQL query that reproduces this alleged problem. The
functions in class SqlFunctions exist ONLY to support the code that is
generated to implement actual SQL functions. It is difficult to reason about
them in abstract - especially when time zones are involved.
> Improper Timezone Handling in SqlFunctions#internalToTimestamp
> ---------------------------------------------------------------
>
> Key: CALCITE-6896
> URL: https://issues.apache.org/jira/browse/CALCITE-6896
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.39.0
> Reporter: wei.chou
> Priority: Major
>
> {*}Error Cause{*}: Improper Timezone Handling in method of
> SqlFunctions.internalToTimestamp(long v)
> # {{LocalDateTime.ofEpochSecond()}} generates a UTC-based timestamp but
> produces a *timezone-less* {{LocalDateTime}} object.
> # {{Timestamp.valueOf(dateTime)}} implicitly uses the *JVM's default
> timezone* to interpret the {{{}LocalDateTime{}}}, rather than preserving the
> UTC context. This creates a hidden timezone conversion.
> {*}Example{*}:
> If {{v = 1741363199000}} (UTC epoch: 2025-03-07 15:59:59) and the system
> timezone is UTC+8:
> * {{LocalDateTime}} correctly represents 2025-03-07 15:59:59 (UTC)
> * {{Timestamp.valueOf()}} treats it as 2025-03-07 15:59:59 {*}in UTC+8{*},
> resulting in an actual UTC time of 2025-03-07 7:59:59.000 (8-hour offset
> error).
> {*}Correct Approach{*}:
> {code:java}
> // Direct conversion without timezone ambiguity
> public static java.sql.Timestamp internalToTimestamp(long v) {
> return new java.sql.Timestamp(v); // Milliseconds directly map to SQL
> Timestamp
> }
> // Or using Instant
> public static java.sql.Timestamp internalToTimestamp(long v) {
> return Timestamp.from(Instant.ofEpochMilli(v));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
