[
https://issues.apache.org/jira/browse/CALCITE-6896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
wei.chou updated CALCITE-6896:
------------------------------
Description:
{*}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}
was:
{*}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 = 0}} (UTC epoch: 1970-01-01 00:00:00) and the system timezone is UTC+8:
* {{LocalDateTime}} correctly represents 1970-01-01 00:00:00 (UTC)
* {{Timestamp.valueOf()}} treats it as 1970-01-01 00:00:00 {*}in UTC+8{*},
resulting in an actual UTC time of 1969-12-31 16:00:00 (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}
> 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)
