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 internally, but certainly it
would be excellent for Solr to transcode different types into Solr Time.
My main problem (as a normal Solr end user) is that it's hard to do
math directly on 8601 dates or really parse them without specific
packages. My XSL 2.0 parsers don't even like it without some
massaging (forget about XSL 1.0.) UNIX time (seconds since the epoch)
is super easy, as are sortable delimitable strings like
"20070510125403."
I'm not sure what delimitable means, but Solr datetimes _are_
essentially sortable inverse-magnitude like the above, with a few
punctuation symbols thrown in. I have no XSLT-fu, but is it not
possible to do regexp-replace s/[TZ:-]//g on the solrdate to get the
above?
I'm not advocating replacing 8601 as the known good Solr Time, just
that some leeway be given in the parser to accept unix time or
something else and the conversion to 8601 happens internally. And a
further dream is to have a strftime formatter in solrconfig for the
query response, so I can always have my date fields come back as "May
10th, 2007, 12:58pm."
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?
regards
-Mike
