Existing date/time types are now represented by UNSIGNED_DATE, UNSIGNED_TIME, and UNSIGNED_TIMESTAMP. If you have code that matches on DATE, TIME, or TIMESTAMP, it should be changed to use the UNSIGNED equivalent.

Also, not sure if you've done this yet, but you should run your tables through our upgrade process: http://phoenix.incubator.apache.org/upgrade_from_2_2.html

This will (among other things), change the metadata as described above (so if you're not explicitly referencing PDataType date/time types, but driving off of the DatabaseMetaData calls, no change would be necessary).

The reason we made this change, is so that we can support negative date/time values (which we've had a few requests for).

Thanks,

James

On Fri, Apr 4, 2014 at 8:03 AM, Abe Weinograd <abe@flonet.com> wrote:

We are bulk loading rows into our HBase tables directly via M/R -> HFiles.  This worked well in 2.2.3 and has broken with 3.0.

We have a 3 column PK (int, date, int).  When I insert directly via the JDBC driver, everything works well.  When loading via the HFile, logging the Hex String from our M/R job and doing a scan on the table in the hbase shell, it shows this:

The first 12 bytes (int then date) of our key looks like this on the scan: 

\x00\x00\x00\x06\x00\x00\x1D\x8F\xD5&\x84\x00

x00\x00\x1D\x8F\xD5&\x84\x00 was supposed to represent 12/31/2999 00:00:00 UTC

The long value is 32503593600000L

We are using hbase client util Bytes.toBytes(32503593600000L) to get our value.  It seems like a change in the PDataType code causes this not to work anymore with 3.0.

Does this make sense?  Is there an easy way for us to fix it?  I know the Bytes.toBytes() representation looks funny with the & in it, but it seems to work across the board.

Any ideas how we can work around this?

Thanks,

Abe