Not sure if this has been reported or not. I checked the issues with a few key phrases, but didn't find anything.

Found in GWT Release (e.g. 2.4.0, 2.5.1, trunk):

GWT 2.7.0

Encountered on OS / Browser (e.g. WinXP, IE9, FF10):

Windows 8.1, FireFox 38.0.5, Chrome 43.0.2357.130 m, IE 11

Detailed description (please be as specific as possible):

DateTimeFormat.parseStrict will incorrectly parse date strings that are not in the specified format.

For example, dates in the format of "MM/dd/yyyy" will be correctly parsed when specifying the format "M/d/yyyy" and vice versa.

This makes DateTimeFormat.parseStrict too lenient for verifying date string formats.

Shortest code snippet which demonstrates issue (please indicate where actual result differs from expected result):

String testDateString1 = "1/1/2000"; String testDateString2 = "01/01/2000";

Date parsedDate1 = DateTimeFormat.getFormat("MM/dd/yyyy").parseStrict(testDateString1); //expected IllegalArgumentException - not thrown

Date parsedDate2 = DateTimeFormat.getFormat("M/d/yyyy").parseStrict(testDateString2); //expected IllegalArgumentException - not thrown

Workaround if you have one:

Can create a properly formatted dateString with DateTimeFormat and compare to original input string.

if (!DateTimeFormat.getFormat("MM/dd/yyyy").format(parsedDate).equals(testDateString)) { //do error handling here }

I believe this is by design. From the javadoc, the number of pattern letters is the minimum required number of digits. This means that 1/1/2000 would fail to parse as MM/dd/yyyy, but 01/01/2000 is OK for M/d/yyyy. Still from the javadoc, the strict vs. lenient caracteristics of the methods control whether an empty input is legal or not, whether the input should be consumed completely, and how dates after they've been parsed should be handled when invalid (e.g. the February 30th, or June 31st, or the 13th month of the year).

BTW, we've moved the issue tracker to GitHub, see links in: http://www.gwtproject.org/lifeofanissue.html

You state that "1/1/2000" would fail to parse as "MM/dd/yyyy", which is not true and is exactly the bug i've posted that you've closed.

Oh sorry, I had read a bit too fast!

Anyway, please file the issue over on GitHub.