Date in yyyyy-mm-dd format not throwing error

Question

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

Is your issue that you don't think 10 October 20155 is a valid date, or that you expect `yyyy` to specifically not match 5-digit years? — Matt Gibson, Jan 09 '15 at 22:47
I expect yyyy not to match 5 digit years. I know 20155 is a valid year. — VamsiKrishna, Jan 09 '15 at 22:50
So it sounds like you've found a bug! Perhaps you should report it to the authors of the product. — Joe Wicentowski, Jan 10 '15 at 00:53

score 4 · Accepted Answer · answered Jan 10 '15 at 10:30

This is expected and documented behavior, although admittedly surprising.

OSB Date Patterns

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.

Java Date Patterns

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.

To my ears, the first bit of documentation is a little misleading/contradictory. "Repeat each symbol to match the *maximum* number of characters required to represent the actual value" seems to imply that you *would* need `yyyyy` to represent 20155, as the maximum number of characters you'd need to represent the value 20155 is 5, not 4. (But I completely understand that `yyyy`, following all the Y2K frenzy, might well be coded to mean "anything other than a 'Y2K-problem' 'two digit year', damn it...", and that what we're seeing here is the specified and correct Java behaviour.) — Matt Gibson, Jan 10 '15 at 10:54
I read that phrase with "maximum" being related to "required", with four `Y` requiring four digit years, but _allowing_ more of them. But indeed, there are possibly lots of variants to read that phrase... — Jens Erat, Jan 10 '15 at 11:07

Date in yyyyy-mm-dd format not throwing error

1 Answers1

OSB Date Patterns

Java Date Patterns