I see that the version long value can also be set manually, which is probably happening in my case and the reason I am not able to match the timestamps. Initially I was wondering if this had something to do with the offsets in the Calendar object. If I print the timestamp value using the KeyValue#getTimestamp() method, I get an 16 digit number. When I try to get the date value using this number and the link you provided, it says 'Invalid Date' which is probably the app's limit, but if I set this number in java.util.Calendar, I get a 5 digit year.
Thanks for the reply and the links. On Fri, Oct 18, 2013 at 3:15 PM, Ted Yu <[email protected]> wrote: > bq. the hbase timestamp long value has more digits than the one created in > Java. > > Can you give us an example ? > In the following, > http://www.ruddwire.com/handy-code/date-to-millisecond-calculators/ gives > me the date corresponding to timestamp value(s): > > hbase(main):007:0> scan 'test' > ROW COLUMN+CELL > row1 column=cf:a, timestamp=1288380727188, value=value1 > row2 column=cf:b, timestamp=1288380738440, value=value2 > > > > On Fri, Oct 18, 2013 at 12:55 PM, Hrishikesh P <[email protected] > >wrote: > > > How are the timestamps associated with cell versions within HBase > > similar/different to the long values that I get using > > System.currentTimeMillis() in Java? If I print both, the hbase timestamp > > long value has more digits than the one created in Java. > > Aren't both milliseconds since Jan 1, 1970? > > > > Thanks in advance. > > >
