[
https://issues.apache.org/jira/browse/CALCITE-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17643974#comment-17643974
]
Gregory Hart commented on CALCITE-5414:
---------------------------------------
I think I saw a comment somewhere about not hardcoding specific timezones such
as UTC. I noticed that AbstractCursor.TimestampAccessor.getString() and
CatchallSchema are both hardcoded to UTC, but that means getString() has
different behavior between TimestampAccessor and TimestampFromNumberAccessor. I
saw a few solutions to this problem:
* *Leave the current behavior as-is.* This would break the
JdbcTest.testDynamicTimestampToSqlTimestamp() test that I added where it sets a
dynamic parameter to Timestamp.valueOf("1500-04-30 12:00:00") and uses
TimestampAccessor to verify that ResultSet.getString() and
ResultSet.getTimestamp() return the same value. This would also provide
different results than JdbcTest.testLiteralTimestampToSqlTimestamp() that uses
the TimestampFromNumberAccessor and does provide the same value for both
ResultSet.getString() and ResultSet.getTimetsamp().
* *Set the time zone for QuidemTest to UTC.* Since the date and time values in
CatchallSchema are set relative to UTC, I can set the time zone for the
"catchall" schema in QuidemTest to UTC. This ensures that the behavior matches
CalciteAssert that sets the time zone to UTC.
* *Modify CatchallSchema to use the default time zone.* I can change the date
and time values in CatchallSchema to be relative to the default time zone, but
RelativeSchemaTest assumes that the values will be in UTC. I'd need to set the
time zone for 3 tests in RelativeSchemaTest to be the default time zone.
I went with the 2nd option, but I'd be willing to go with another solution if
setting the time zone to UTC is not preferred.
> Use DateTimeUtils to correctly convert between java.sql types and unix
> timestamps
> ---------------------------------------------------------------------------------
>
> Key: CALCITE-5414
> URL: https://issues.apache.org/jira/browse/CALCITE-5414
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.32.0
> Reporter: Gregory Hart
> Assignee: Gregory Hart
> Priority: Major
> Labels: pull-request-available, pull-requests-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Converting java.sql types to unix timestamps requires extra steps to also
> convert to the correct calendar. Unix timestamps should follow the proleptic
> Gregorian calendar as defined by ISO-8601. Java uses the standard Gregorian
> calendar for java.sql types and switches to the Julian calendar for dates
> before the Gregorian shift.
> The DateTimeUtils class in Avatica correctly handles the calendar
> conversions. Calcite should use those methods since its own methods do not
> currently convert between calendars.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
