On 08/08/2014 09:38, Michael Dürig wrote: > > Are you sure about the 'Z'? AFAIR (*) the time zone part is left to > whatever the user specified when setting a date property (e.g. > 2014-08-08T09:21:55.123+01:00). You're absolutely right. An actual key in the index is
2014-04-22T10%3A11%3A24.002%2B01%3A00 that translated is 2014-04-22T10:11:24.002+01:00 and by looking at it we could hit a similar stuff as OAK-1763 with range queries if have different time zones. Although it's more likely not to happen as the indexing and dating happens on the server side and as long as the server doesn't change the timezone JVM settings all the dates will be on the same TZ. Leaving the encoding issue (OAK-1763) aside we could work anyhow by zeroing the aspects we don't want like the milliseconds, having therefore the above date as 2014-04-22T10:11:24.000+01:00 if we want to cancel the millisecond precision or 2014-04-22T10:11:00.000+01:00 if we want to cancel the second precision. Assuming we go for a configurable approach the question still remain: what will it be a good approximation for sorting? I'm for cancelling the millisecond precision by default as I think that most use cases won't care if within the same second the items are not in the perfect order. The configurable options will be IMO: none, millis, seconds but we can easily provide even lesser precision options. Thoughts? D.
