On 7-May-08, at 5:04 AM, Daniel Papasian wrote:
Chris Hostetter wrote:
The two exceptions you cited both indicate there was at least one
date
instance with no millis included -- NOW can't do that. it always
inlcudes
millis (even though it shouldn't).
I've seen people suggest, for performance reasons, that they reduce
the
granularity of the timestamps they're storing down to what they need -
i.e. minute, hour, or day, instead of millisecond. But it seems that
functionality will break if you don't store it with millis.
I'm just trying to make sure I'm reconciling these here-- Is the
goal of
reducing the granularity simply to reduce the cardinality of the
indexed
date terms? If so, is the best practice when you don't need
significance beyond date to just fill the rest of the date with zeros,
and index, say, 2008-07-05T00:00:00.000Z?
That is exactly the goal, and the padding solution would definitely
work. It might be safer to just recommend not using NOW when
granularizing dates.
(Hope this doesn't count as a threadjack!)
Since you are actually replying to a message in the thread, I don't
see how it could be :)
-Mike
