Hi Mauricio,
Thanks for the suggestions :) I'm already running mono 2.10.5 so i
should be safe..
And thanks to everybody for quick answers and friendly attitude.
Best regards,
Nicklas
On 2011-09-13 03:01, Mauricio Scheffer wrote:
Hi Nicklas,
Use a nullable DateTime type instead of MinValue. It's semantically more
correct, and SolrNet will do the right mapping.
I also heard that Mono had a bug in date parsing, it didn't behave just like
.NET :
https://github.com/mausch/SolrNet/commit/f3a76ea5535633f4b301e644e25eb2dc7f0cb7ef
IIRC this bug was fixed in Mono 2.10 or so, so make sure you're running the
latest version.
Finally, there's a specific mailing list for questions about SolrNet:
http://groups.google.com/group/solrnet
Cheers,
Mauricio
On Mon, Sep 12, 2011 at 7:54 AM, Nicklas Overgaard<nick...@isharp.dk>wrote:
I see. I'm using that date to flag that my entity "has not yet ended". I
can just use another constant which Solr is capable of returning in the
correct format. The nice thing about DateTime.MinValue is that it's just
part of the .net framework :)
Hope that the issue is resolved at some point.
I'm wondering if it would be possible for you (or someone else) to fix the
issue with years from 1 to 999 being formatted incorrectly, and then
creating a new ticket for the issue with negative years?
Best regards,
Nicklas
On 2011-09-12 07:02, Chris Hostetter wrote:
: The XML output when performing a query via the solr interface is like
this:
:<datename="endDate">1-01-**01T00:00:00Z</date>
i think you mean:<date name="endDate">1-01-01T00:00:**00Z</date>
:> > So my question is: Is this a bug in the solr output engine, or
should mono
:> > be able to parse the date as given from solr? I have not yet tried
it out
:> > on .net as I do not have access to a windows machine at the moment.
it is in fact a bug in Solr that not a lot of people have been overly
concerned with some most people don't deal with dates that far back....
https://issues.apache.org/**jira/browse/SOLR-1899<https://issues.apache.org/jira/browse/SOLR-1899>
...I spent a little time working on it at one point but got side tracked
by other things since there are a coupld of related issues with the
canonical iso8601 date format arround year "0" that made it non obvious
what hte "ideal" solution was.
-Hoss
