: One great problem we are having to integrate solr with plone is that
: plone can have dates and times in diferent timezones, and each user can query
: the data in its own timezone. So we would be really interested in being able
: to put date/time data on solr with a timezone and specifying
One great problem we are having to integrate solr with plone is that
plone can have dates and times in diferent timezones, and each user
can query the data in its own timezone. So we would be really
interested in being able to put date/time data on solr with a timezone
and specifying the t
e.org
Subject: Re: dates & times
: It's more than string processing, anyway. I would want to convert the
: Solr Time 2007-03-15T00:41:5:2Z to "March 15th, 2007" in a web app.
: I'd also like to say 'Posted 3 days ago." In my vision of things,
: that work is done
(In general a "DateTranslatingTokenFilter" class would be a pretty cool
addition to Lucene, it could as constructor args two DateFormatters (one
for parsing the incoming tokens, and one for formating the outgoing
If this happens, it would be nice (perhaps overkill) to have a "chronic"
input fi
: The right approach for more flexible date parsing is probably to add
: more functionality to the date field and configure via optional
: attributes.
Adding configuration options to DateField seems like it might ultimately
be the right choice for changing the *internal* format, but assuming we
w
On 5/10/07, Brian Whitman <[EMAIL PROTECTED]> wrote:
On May 10, 2007, at 2:30 PM, Chris Hostetter wrote:
> Questions like these are whiy I'm glad Solr currently keeps it
> simple and
> makes people deal in absolutes .. less room for confusion :)
I get all that, thanks for the great explanation.
On May 10, 2007, at 2:30 PM, Chris Hostetter wrote:
Questions like these are whiy I'm glad Solr currently keeps it
simple and
makes people deal in absolutes .. less room for confusion :)
I get all that, thanks for the great explanation.
I imagine most of my problems can be solved with a cus
to Solr is also
desirable.
Peter
-Original Message-
From: Brian Whitman [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 12:25 PM
To: solr-user@lucene.apache.org
Subject: Re: dates & times
> You can get at some of this functionality in the built-in xslt 1.0
> engine (X
: It's more than string processing, anyway. I would want to convert the
: Solr Time 2007-03-15T00:41:5:2Z to "March 15th, 2007" in a web app.
: I'd also like to say 'Posted 3 days ago." In my vision of things,
: that work is done on Solr's side. (The former case with a strftime
: type formatter in
You can get at some of this functionality in the built-in xslt 1.0
engine (Xalan) by using the e-xslt date-time extensions: see
http://exslt.org/date/index.html, and for Xalan's implementation see
http://xml.apache.org/xalan-j/extensionslib.html#exslt .
The exslt stuff looks good, thanks! I'll h
ECTED]
Sent: Thursday, May 10, 2007 11:49 AM
To: solr-user@lucene.apache.org
Subject: Re: dates & times
>
> Those are interesting ideas and it probably would not be difficult to
> create a patch if you were interested, but I'm curious: What about
> XSL makes what
Those are interesting ideas and it probably would not be difficult to
create a patch if you were interested, but I'm curious: What about
XSL makes what seems to me an elementary string-processing task so
difficult?
Well, XSL 1.0 (which is the one that "comes for free" with Solr/java)
doesn'
On 5/10/07, Brian Whitman <[EMAIL PROTECTED]> wrote:
After writing my 3rd parser in my third scripting language in so many
months to go from unix timestamps to "Solr Time" (8601) I have to
ask: shouldn't the date/time field type be more resilient? I assume
there's a good reason that it's 8601 int
After writing my 3rd parser in my third scripting language in so many
months to go from unix timestamps to "Solr Time" (8601) I have to
ask: shouldn't the date/time field type be more resilient? I assume
there's a good reason that it's 8601 internally, but certainly it
would be excellent fo
14 matches
Mail list logo
