Unix timestamps are implicitly UTC. Avatica (and standard SQL) timestamps have no time zone.
Sorry to be pedantic. I know I’ve said it before, and I know it’s just semantics. Until someone starts writing code to do timezone shifts. Julian > On Apr 7, 2016, at 7:26 AM, Josh Elser <[email protected]> wrote: > > Yep, unix timestamp in the `number_value` attribute should be correct. > > If you have more questions about how to serialize TypedValue's before I get > some more docs in place, this method[1] should help. This was a recent > consolidation which should be pretty easy to follow (even without knowing > Java). > > Thanks for creating the JIRA issue. I'll go ahead and give you the karma to > have a bit more control in assigning issues in the CALCITE project while I'm > at it. > > [1] > https://github.com/apache/calcite/blob/master/avatica/core/src/main/java/org/apache/calcite/avatica/remote/TypedValue.java#L480 > > F21 wrote: >> Sure thing! In the mean time, can you answer my question regarding >> whether setting the type to JAVA_SQL_TIMESTAMP and setting number_value >> to the unix timestamp is correct? >> >> On 7/04/2016 8:36 AM, Josh Elser 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! >>>>>>> >>>>>>> >>>> >>>> >>
