[
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16530409#comment-16530409
]
Kenneth Knowles commented on CALCITE-2394:
------------------------------------------
I believe the calls go like so:
1. ResultSet.getString(col)
2. AvaticaResultSet.getString(col))
3. AvaticaResultSet.getAccessor(col).getString()
4. TimestampAccessor.getString()
5. timestampAsString(TimestampAccessor.getNumber())
6. DateTimeUtils.unixTimestampToString(getNumber() - offset)
7. DateTimeUtils.unixTimestampToString(AvaticaSite.toBigDecimal(col) - offset)
I would describe this as applying timezone translation before converting to
string. It does not convert to java.sql.Timestamp.
To set up a fuller example for consideration, which I imagine is fairly
pedestrian: I have a CSV in text or Kafka (etc) with unix timestamps. A user
imposes a schema on it (CREATE TABLE ... LOCATION ...). They claim that column
has type TIMESTAMP. Can I make this always have zero offset? My reading of your
advice is that the user must impose the type TIMESTAMP WITH TIME ZONE and we
always return a timezone with offset 0. TBH this path has not been on my radar
so I don't know if it turns out well. It would be much nicer for users if they
didn't have to type so much.
> Avatica applies calendar offset to timestamps when they should remain
> unchanged
> -------------------------------------------------------------------------------
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> Reporter: Kenneth Knowles
> Assignee: Kenneth Knowles
> Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three
> different accessors:
> {code}
> class AbstractCursor {
> ...
> static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
> v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
> }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates
> millis-since-epoch from a date, so applying the offset is appropriate to hit
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}}
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale
> (in addition to later display adjustments).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
