On Aug 15, 2009, at 10:11 AM, Yonik Seeley wrote:
Now that we have date fields that internally store milliseconds (and can currently be used in function queries) we have the basis for a good replacement for using things like ord(date)... which is now a bad idea since it causes the FieldCache to be instantiated at the highest level reader... doubling the usage if it's also used for faceting or sorting. One issue though is that our float functions don't have enough precision to deal with dates that well. System.currentTimeMillis() currently contains 13 digits. A float can capture 7.x digits of precision.
Along this lines, does the DateField FieldType only allow you to store at precision milliseconds? I know w/ Trie you can encode other precision levels, but in some cases maybe all I want is the hour/day/ year/whatever, it would be nice not to have to think about this on the client side. Perhaps I am just missing something. In other words, do we support Lucene's DateTools Resolution capabilities?
This means that our 10^-3 seconds precision on the raw date field is only accurate to 10^3 seconds (~15minutes) when converted to a float. We could either: - change function queries to use doubles internally - probably a good idea for the future in general - seems like geo might need more precision too. - come up with a new date scale function that uses doubles internally? -Yonik http://www.lucidimagination.com
