[
https://issues.apache.org/jira/browse/PHOENIX-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354956#comment-17354956
]
Istvan Toth commented on PHOENIX-6486:
--------------------------------------
Browsing the time handling code, Phoenix mixes java.util.Date style functions
and Joda Time functions freely, even though they are using different
Chronologies.
For example, we parse date types with Joda Time (ISOChronology), but format
them with j.u.Date (GJChronology)
The behaviour is roughly the following:
When upserting records:
* Dates specified in date literals are stored according to ISOChronology
* Dates specified as java.sql.Date for preparedStatements are are stored
according to GJChronology
Internal processing:
* Date functions mostly use joda.time and interpret stored dates according to
ISOChronology
When selecting records:
* Dates are returned as stored epoch long.
* When converting to string, they are interpreted according to GJChronology
It would be a big improvement if we used either ISOChronology or GJChronology
internally consistently.
For using GJChronology:
* Fully compatible and surprise-free with the JDBC API
* Even the JDBC java.time convenience methods use GJCalendar internally
* inconsistent with default Joda Time and java.tima API chronologies
Against using GJChronology:
* GJCalendar is not trivially supported by the java.time API (future proofing)
* Java is generally moving to ISOCalendar as default
* Must be careful to override the default chronology for every joda/java.time
function in the code
For using ISOChronology
* Internally consistent with default Joda Time and java.time chronologies
* Don't need to be careful with the Joda/java.time API in the Phoenix code.
* Existing Records are internally interpreted to be in the ISO chronology (for
date functions)
Against using ISOChronology
* Temporal result types (java.sql.Date etc) will be in the wrong chronology
(unless we attempt to convert those back, which sounds risky)
* The same is true when adding dates via the PreparedStatement interface, they
will be in the bad chronology, unless processed explicitly.
Unknowns:
* performance hit for using non-default chronologies ?
* performance of j.u.Date vs joda / java.util.Date ?
> Phoenix uses JodaTime ISO calendar internally, which is incompatible with the
> JDK time representation
> ------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-6486
> URL: https://issues.apache.org/jira/browse/PHOENIX-6486
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 5.1.1, 4.16.1
> Reporter: Istvan Toth
> Priority: Major
>
> Phoenix does a lot of internal Time processing using JodaTime.
> However, the default Chronology for JodaTime is ISO,
> while the default chronology used by the JDK is GregorianJulian
> https://www.joda.org/joda-time/cal_gj.html
> This causes pre-cutover date handling to fail spectacularly:
> {noformat}
> > create table bubu (id integer primary key, ts timestamp);
> 1 row affected (0.059 seconds)
> > upsert into bubu values (1, '1-1-1 0:0:0');
> 1 row affected (0.007 seconds)
> > select * from bubu;
> +----+-----------------------+
> | ID | TS |
> +----+-----------------------+
> | 1 | 0001-01-03 01:00:00.0 |
> +----+-----------------------+
> 1 row selected (0.014 seconds)
> > select id, year(ts), month(ts), dayofmonth(ts), hour(ts), minute(ts),
> > second(ts) from bubu;
> +----+----------+-----------+----------------+----------+------------+------------+
> | ID | YEAR(TS) | MONTH(TS) | DAYOFMONTH(TS) | HOUR(TS) | MINUTE(TS) |
> SECOND(TS) |
> +----+----------+-----------+----------------+----------+------------+------------+
> | 1 | 1 | 1 | 1 | 0 | 0 | 0
> |
> +----+----------+-----------+----------------+----------+------------+------------+
> 1 row selected (0.014 seconds)
> {noformat}
> The one hour difference is coming from my being in CET instead of GMT.
> This specific problem is the two day difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
