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 >> > >
