Support indexing dates before the java epoch

Support indexing dates before the java epoch

Original JIRA Issue: https://geomesa.atlassian.net/browse/GEOMESA-1785

Key: GEOMESA-1785
Type: Improvement
Priority: Major
Status: To Do
Resolution: Unresolved
Reporter: Emilio Lahr-Vivaz
Created: Mon, 24 Apr 2017 09:28:23 -0400
Updated: Fri, 28 Apr 2017 16:14:28 -0400

Comments:

557058:85267d80-736b-42c9-898c-3b6267da6a7f (Fri, 28 Apr 2017 16:10:17 -0400):

Would it matter if the epochs before the java epoch sorted after the epochs after the java epoch? Conceptually it seems wrong, but in practice we bin everything by epoch. It could constrain us in the future for querying unbounded dates, but we would still know the 'flip point'.

Our current encoding of epochs:
scala> Shorts.toByteArray(0).map("%02X" format _).mkString res5: String = 0000 scala> Shorts.toByteArray(-1).map("%02X" format _).mkString res7: String = FFFF scala> Shorts.toByteArray(Short.MaxValue).map("%02X" format _).mkString res8: String = 7FFF scala> Shorts.toByteArray(Short.MinValue).map("%02X" format _).mkString res9: String = 8000

557058:85267d80-736b-42c9-898c-3b6267da6a7f (Fri, 28 Apr 2017 16:14:28 -0400):

Might just need to edit BinnedTime to check for dates before the epic and switch the sign on the weeks/months/etc.

Start by reading BinnedTime and the current epoch encoding described in the issue. Determine how dates before the Java epoch should be binned and ordered, then verify that indexing supports those dates without breaking existing epoch behavior. No test file is named, so identify the relevant indexing tests before making changes.