bq. I get a 5 digit year. That explains it :-)
On Fri, Oct 18, 2013 at 2:13 PM, Hrishikesh P <[email protected]>wrote: > 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. > > > > > >
