[
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)
