Well this might appear weird, but I see, while converting a string to date, the value 20155-10-10 didn't throw an error saying invalid date.
the function used is as below
fn-bea:date-from-string-with-format("MM/dd/yyyy",'10/10/20155')
the above functioned returned date 20155-10-10, when above string is passed and was validated by the schema too. the field is declared as type xs:date
the prototype of the function is
fn-bea:date-from-string-with-format($format as xs:string?, $dateString as xs:string?) as xs:date?
please follow the link http://docs.oracle.com/cd/E13167_01/aldsp/docs25/xquery/extensions.html#wp1297249 for the function usage and example
This is expected and documented behavior, although admittedly surprising.
The Oracle documentation on fn-bea:date-from-string-with-format(...) contains following note on date patterns (highlighting added by me):
You can construct date and time patterns using standard Java class symbols. [...] Repeat each symbol to match the maximum number of characters required to represent the actual value. [...]
So, OSB uses the default Java date patterns, and YYYY sets the date to require at least four digit year declaration, but allows arbitrary longer ones. For example, MM/dd/yyyy matches 23/02/2014 and 23/02/20155; but not 23/02/42.
Looking at the Java specifications to verify this, even the last date (in year 42) would be allowed:
For parsing, if the number of pattern letters is more than 2, the year is interpreted literally, regardless of the number of digits. So using the pattern "MM/dd/yyyy", "01/11/12" parses to Jan 11, 12 A.D.
It might be OSB uses their own parsing rules together with the Java date class symbols.
I didn't verify against OSB which one is used, but both specifications do allow five-digit years for YYYY.