: When using SolrJ I've realized document dates are being modified according : to the environment UTC timezone. The timezone is being set in the inner : class ISO8601CanonicalDateFormat of DateField class.
The dates aren't "modified" based on UTC, they are formated in UTC before being written to the Lucene index so that no matter what the current locale is the index format is consistent. : I've read some posts where people say Solr should be most locale and culture : agnostic. So, what's the purpose for that timezone processing before The use of UTC is specificly to be agnostic of where the server is running. Any client, any where in the world, using any TimeZone can query any solr server, running in any JVM, and know that the dates it gets back are formated in UTC. : Code to simulate issue: I don't actaully see any "issue" being simulated in this code, can you elaborate on how exactly it's behaving in a way that's inconsistent with your expectaitons? (making it a JUNit TestCase that uses assserts to fail where you are getting data you don't expect is pretty must the universal way to describe a bug) My guess would be that you are getting confused by the fact that Date.toString() uses the default locale of your JVM to generate a string, which is why the data getting printed out doesn't match the hardcoded value in your code... : System.out.println(dateField.toObject(field)); but if you take any Date object you want, print it's toString(), index it, and then take that indexed string representation convert it back into a Date (using dateField.toOBject()) you should originalDate.equals(newDate). -Hoss
