Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 19 Oct 2007 17:40:32 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: solr-user@lucene.apache.org
Subject: Re: Solr, operating systems and globalization
In-Reply-To: <1D110EAF-C621-4BD8-A903-9A63F714A9BB@gmail.com>
Message-ID: <Pine.LNX.4.62.0710191722530.640@radix.cryptio.net>
References: <50f433360710120840n5fba9596r43873969ad451541@mail.gmail.com>
 <Pine.LNX.4.62.0710171338570.1407@radix.cryptio.net>
 <39135184-8B64-4064-900E-AD50BFDEE8D0@gmail.com>
 <Pine.LNX.4.62.0710181139090.17904@radix.cryptio.net>
 <1D110EAF-C621-4BD8-A903-9A63F714A9BB@gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

: 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