Hi Mauricio, The docs you linked to are for Impala, not Kudu. Kudu's timestamp type internally keeps microsecond precision. Your example of multiplying by 1000 is correct; you should adjust whatever your timestamp is to microseconds since the unix epoch. There are a bunch of different time APIs on the JVM, so perhaps your preferred timestamp API has a dedicated toMicroSeconds() or something like that. The abundance of time APIs is why we've thusfar punted on adding specialized setters to PartialRow.
- Dan On Wed, May 2, 2018 at 3:43 PM, Mauricio Aristizabal <mauri...@impact.com> wrote: > Impala docs > <https://www.cloudera.com/documentation/enterprise/5-13-x/topics/impala_timestamp.html> > indicate that "Kudu represents date/time columns using 64-bit values" and > also that "the time portion of a TIMESTAMP value is in nanoseconds", and I > know a Java Date "stores time in milliseconds since January 1, 1970" so > since there is no partialRow.addTimestamp I did a > > partialRow.addLong(someJavaUtilDate.getTime() * 1000) > > and that seems to work, but it's kinda hokey. Am I doing this right? > > Also, would be nice to update the java sample > <https://github.com/cloudera/kudu-examples/blob/master/java/java-sample/src/main/java/org/kududb/examples/sample/Sample.java> > with a few more column types and operations. > > thanks, > > -m > > -- > Mauricio Aristizabal > Architect - Data Pipeline > *M * 323 309 4260 > *E *mauri...@impact.com | *W * https://impact.com > <https://www.linkedin.com/company/608678/> > <https://www.facebook.com/ImpactMarTech/> > <https://twitter.com/impactmartech> > > > <http://impactgrowth.com> >
