And to stop the argument before it starts… there shall be no timezone conversion of date/time/timestamp values as they go into protobuf format or come out of it. They do not contain a timezone. They are not implicitly in UTC. The timestamp value 0 means “1970-01-01 00:00:00” and it is up to the user what timezone, if any, that is to be interpreted in.
> On Apr 6, 2016, at 3:36 PM, Josh Elser <[email protected]> wrote: > > Ok. You got me thinking that it would be good to document how each support > type in TypedValue is serialized into that message (as it isn't necessarily > obvious how the code expects it). > > Want to file a JIRA issue and assign it to me? > > F21 wrote: >> Hey Josh, >> >> That was a great explanation, thanks! And yes, I am using protobufs. :) >> So in the case of a date time, should I set the Rep to >> JAVA_SQL_TIMESTAMP and set the number_value field to the unix timestamp >> equivalent of the datetime? >> >> I am not familiar with Java, but it would also be nice if the docs could >> include the format JAVA_SQL_* with an example. >> >> Thanks again! >> >> On 7/04/2016 12:37 AM, Josh Elser wrote: >>> Also, if you have suggestions on how you'd like to see the >>> documentation expanded, please do provide them. I can try to expand, >>> but if I don't have a focus on what is actually lacking, it's hard to >>> be effective. >>> >>> Josh Elser wrote: >>>> If you're using Protobuf (as I think you are), you don't need to worry >>>> about the conversion from the Protobuf TypedValue message back into the >>>> Avatica class TypedValue. This is handled implicitly by Avatica itself. >>>> Just make sure that the Rep you provide matches the serialization. >>>> >>>> I'm not familiar with golang's SQL interface, so I'm not sure what they >>>> define as a "datetime" here. If you have more specifics, I can try to >>>> point you in the right direction. >>>> >>>> AFAIK, there isn't any difference in implementation between >>>> PRIMITIVE_FOO and FOO (there are a few variants of this). >>>> >>>> The difference between Long and BigInteger would be the resulting Java >>>> type created for the value (a Long or a BigInteger). Sorry if this is >>>> cyclic logic :) >>>> >>>> Yes, the JAVA_* types are used to support the array of >>>> date/time/datetime data types. >>>> >>>> F21 wrote: >>>>> I need to send some TypedValues to the avatica server (phoenix query >>>>> server) when executing a statement. >>>>> >>>>> According to >>>>> https://calcite.apache.org/docs/avatica_protobuf_reference.html#typedvalue, >>>>> >>>>> >>>>> I need to set a Type for each value. I noticed that the list of Reps >>>>> here >>>>> (https://calcite.apache.org/docs/avatica_protobuf_reference.html#rep) >>>>> support things like JAVA_SQL_TIME, JAVA_SQL_TIMESTAMP etc, however it's >>>>> unclear which ones are valid values for a TypedValue. >>>>> >>>>> In my case, the golang sql interface provides data for parameter >>>>> binding >>>>> that might be a time.time (which is essentially a datetime). In this >>>>> case, what should my TypedValue look like? >>>>> >>>>> Also, I noticed the Rep enum has a few things that looked similar, but >>>>> might mean different things. It would be nice to have documentation to >>>>> clarify. For example: >>>>> - What's the difference between PRIMITIVE_BOOLEAN and BOOLEAN? >>>>> - Is there any difference between LONG and BIG_INTEGER? >>>>> - Are the JAVA_SQL_* and JAVA_UTIL_* types currently being used? >>>>> >>>>> Thanks! >>>>> >>>>> >> >>
