: Ah, that is good. So if: : : $ date : Thu Oct 18 12:07:42 PDT 2007 : : Then NOW in Solr will be the absolute date Thu Oct 18 04:07:42 2007 (which is : the current time in UTC)?
first off: PDT is only 7 hours off UTC Second: i'm going to get a little bit pedandic... NOW is "now" .. it's an abstract DateTime instance, a point in the one-dimensional space representing linear time. TimeZones are an artificial concept that exist only in the perspective of an observer who places a coordinate system (with an origin) in that dimension. When you try to express an abstract DateTime instance in an email (or in an HTTP response) it stops being an abstract moment in time, and becomes a string representation of a DateTime instance relative that coordinate system. If string representation includes a TimeZone delcaration (and as much precision as is measurable in your universe, but for now lets gloss over that and assume milliseconds is a quantum unit and all string representations include millisecond precision), then that string representation is unambiguous. (just as refering to a point in space using coordinates requires you to have an origin and a unit of distance in order for it to be unambiguous). "Thu Oct 18 12:07:42 PDT 2007" and "Thu Oct 18 05:07:42 UTC 2007" are both unambiguous string representations of the same moment in time. they happen to be relative differnet origins, but the information about the differnece in their orrigins is included in their string representation. Date objects in java represent abstract moments in time, and Solr uses those abstract objects when doing all of it's date based calculations. when it's neccessary to know about the "coordinate system" (in order to represent as a string, or to do rounding or math) Solr uses the UTC coordinate system. : I'm not sure this is desirable. If your user's are all over the world, you'd : ideally want to round to _their_ timezone, but I don't see how this is : realistic. hence the reason it's not implemented yet :) in theory, we should at least allow the schema to specify what the "normal" TimeZone and Locale are for a date field ... and then let clients specify alternative per request ... this would only affect the computation of info (and perhps the string representations accepted from clients or returned to clinents) the string representations stored in the physical index should always be in UTC. -Hoss
