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 s
: 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 th
I see, is the leading - char just ignored then?
> : The following field value for a date field type is accepted:
> : -0001-11-30T00:00:00Z
> :
> : and ends up in the index and as stored value as:
> : 2-11-30T00:00:00Z
> :
> : I'd prefer to be punished with an exception. File a bug?
>
> That is
: The following field value for a date field type is accepted:
: -0001-11-30T00:00:00Z
:
: and ends up in the index and as stored value as:
: 2-11-30T00:00:00Z
:
: 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
Hi,
The following field value for a date field type is accepted:
-0001-11-30T00:00:00Z
and ends up in the index and as stored value as:
2-11-30T00:00:00Z
I'd prefer to be punished with an exception. File a bug?
Thanks
