[jira] [Comment Edited] (PHOENIX-6949) Use j.u.Date.getTimeOffset() for displacement calculation

["Istvan Toth (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-6949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17720425#comment-17720425 ] 

Istvan Toth edited comment on PHOENIX-6949 at 5/8/23 8:00 AM:
--------------------------------------------------------------

This is of a performance vs correctness issue.

A lot of the headache comes from the fact the JVM default Timezone can be changed from within a Java application.
This makes any kind of caching for performance problematic, because in theory there is nothing stopping an application from changing the time zone between any two JDBC calls.

Also, TimeZone.getDefault(), and Calendar.getDefault() are relatively expensive calls, as both include cloning the default values cached internally by the JVM. getDefaultRef(), which omits the cloning has default visibility. 

The current code added in PHONIEX-5066 caches the TimeZone per PhoenixStatement, which is rather arbitrary, and a holdover from earlier fix attempts.

Using getTimezoneOffset() avoids the overhead of cloning the TimeZone, but there is no such shortcut for getting the reverse time displacement.

Looking at the MySql and Postgres JDBC drivers, Mysql simply uses Timezone.getDefault(), while Potstgres uses reflection to access TimeZone.getDefaultRef() (but only on Java 1.8 and earlier.)

The options I can see are:
 * use TimeZone.getDefault(), and accept the perf cost
 * cache TimeZone, and ignore changes in the JVM default TZ
 * make it configurable

The current behaviour is not horrible either, only arbitrary.


was (Author: stoty):
This is of a performance vs correctness issue.

A lot of the headache comes from the fact the JVM default Timezone can be changed from within a Java application.
This makes any kind of caching for performance problematic, because in theory there is nothing stopping an application from changing the time zone between any two JDBC calls.

Also, TimeZone.getDefault(), and Calendar.getDefault() are relatively expensive calls, as both include cloning the default values cached internally by the JVM. getDefaultRef(), which omits the cloning has default visibility. 

The current code added in PHONIEX-5066 caches the TimeZone per PhoenixStatement, which is rather arbitrary, and a holdover from earlier fix attempts.

Using getTimezoneOffset() avoids the overhead of cloning the TimeZone, but there is no such shortcut for getting the reverse time displacement.

Looking at the MySql and Postgres JDBC drivers, Mysql simply uses Timezone.getDefault(), which Potstgres uses reflection to access TimeZone.getDefaultRef() (but only on Java 1.8 and earlier.)

The options I can see are:
 * use TimeZone.getDefault(), and accept the perf cost
 * cache TimeZone, and ignore changes in the JVM default TZ
 * make it configurable

The current behaviour is not horrible either, only arbitrary.

> Use j.u.Date.getTimeOffset() for displacement calculation
> ---------------------------------------------------------
>
>                 Key: PHOENIX-6949
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6949
>             Project: Phoenix
>          Issue Type: Bug
>          Components: core
>            Reporter: Istvan Toth
>            Priority: Major
>
> The current code calculates the offset from the current timezone.
> However, java.util.Date and its children (java.sql.Date*) already provide the getTimeOffset()  for the same.
> -This has the added benefit that in the unlikely case that we receive the a java.sql.Date that is not in the JVM timezone, then we use its offset correctly.-



--
This message was sent by Atlassian Jira
(v8.20.10#820010)