A TimestampString has no timezone. It does not represent a moment in time. It represents a position of the hands on a clock.
A Timestamp does not have a timezone either, but it represents a moment in time. (Internally represented by milliseconds since the UTC epoch.) Therefore, to go from a TimestampString to a Timestamp, or vice versa, you need a time zone. I’m not sure where that should come from in your code. Julian > On Nov 5, 2018, at 1:19 PM, [email protected] wrote: > > Julian, so.. is it correct to translate TimestampString to > java.sql.Timestamp on RexToLixTranslator.convert(...) level as in pull > request https://github.com/apache/calcite/pull/900/commits ? > > > I hope so, then I could revoke pull request > https://github.com/apache/calcite/pull/878 > > > On Mon, Nov 5, 2018 at 9:34 PM Julian Hyde <[email protected]> wrote: > >> Yeah, TimestampString is for SqlNode and RexNode only. Not JDBC code. >> Likewise DateString, TimeString, NlsString. Sorry the doc didn’t make that >> clear. Although frankly it’s impractical to document all of the places >> something is NOT used. >> >>> On Nov 5, 2018, at 5:49 AM, [email protected] wrote: >>> >>> Vladimir, >>> >>> I thought that TimestampString IS the appropriate type :D (knowledge >> based >>> on Rexbuilder code, where TimestampString is being created as >> RexLiteral). >>> >>> My problem is that I don't see what is the scope of TimestampString, >>> DateString, etc in Calcite. Does it span to Rel/Rex tree? Or it should >> not? >>> This is why I've created two different patches :( >>> >>> Any help with the responsibility of TimestampString appreciated. Without >> it >>> - bug is still there and I could create lots of other mishit patches. >> >> > > -- > Piotr Bojko > http://about.me/ptr.bojko
