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? (Hope this doesn't count as a threadjack!) Daniel
