Hi,

The following field value for a date field type is accepted:
<field name="somedate">-0001-11-30T00:00:00Z</field>

and ends up in the index and as stored value as:
<date name="somedate">2-11-30T00:00:00Z</date>

I'd prefer to be punished with an exception. File a bug?

Thanks

: The following field value for a date field type is accepted:
: <field name="somedate">-0001-11-30T00:00:00Z</field>
:
: and ends up in the index and as stored value as:
: <date name="somedate">2-11-30T00:00:00Z</date>
:
: I'd prefer to be punished with an exception. File a bug?

That is actualy a legal date according to the format spec (although there
is seems to be some conflicting guidelines about wether the format allows
a year "0" which makes the interpretation of negative years ambiguious (at
least to me)

There is however already a known bug in SOlr with parsing/formatting dates
prior to year 1000...

https://issues.apache.org/jira/browse/SOLR-1899

...patches most certainly welcome.
-Hoss

I see, is the leading - char just ignored then?

> : The following field value for a date field type is accepted:
> : <field name="somedate">-0001-11-30T00:00:00Z</field>
> :
> : and ends up in the index and as stored value as:
> : <date name="somedate">2-11-30T00:00:00Z</date>
> :
> : I'd prefer to be punished with an exception. File a bug?
>
> That is actualy a legal date according to the format spec (although there
> is seems to be some conflicting guidelines about wether the format allows
> a year "0" which makes the interpretation of negative years ambiguious (at
> least to me)
>
> There is however already a known bug in SOlr with parsing/formatting dates
> prior to year 1000...
>
> https://issues.apache.org/jira/browse/SOLR-1899
>
> ...patches most certainly welcome.
>
>
> -Hoss

: I see, is the leading - char just ignored then?

i'd have to re-look at the tests/docs (i don't really want to repeat
that agonizing headache right now), but i believe what you are seeing is a
compound problem...

* parsing sees the -0001 and recognizes that as a negative year.
* somewhere the negative year is dealt with in a way that assumes there is
  (isn't?) a year 0, making "-1" => "Year 2 BC"
* formatting code doesn't include the era in the output and
  doesn't zero pad propertly so you just get "2" in the response.
-Hoss

That makes sense indeed. Wouldn't it be an idea to test for the single allowed
format before parsing it?

> : I see, is the leading - char just ignored then?
>
> i'd have to re-look at the tests/docs (i don't really want to repeat
> that agonizing headache right now), but i believe what you are seeing is a
> compound problem...
>
> * parsing sees the -0001 and recognizes that as a negative year.
> * somewhere the negative year is dealt with in a way that assumes there is
>   (isn't?) a year 0, making "-1" => "Year 2 BC"
> * formatting code doesn't include the era in the output and
>   doesn't zero pad propertly so you just get "2" in the response.
>
>
> -Hoss