Java验证是否是标准日期

在WEB方面，一般来说从前台传来的日期都是经过验证的（日历控件、JS验证等），所以一般就可以直接使用的，在后台就不需要再做验证了。可是，今天我在项目就遇到这么一个问题，前台传来的日期是上传一个XLS，然后从XLS里面读出来的，所以在前台方面根本无法做验证，只能在后台做验证，我本来直接用SimpleDateFormat转换下，然后我Try catch就可以了。然后在catch里面直接把验证错误信息返回给前台，结果没想到QA在测试的时候，随意输入了一个（13-32-2012），然后SimpleDateFormat.parse()的时候，把13-32-2012(MM-dd-yyyy)转换成了02-01-2013，我本以为它会报错的，然后我可以直接把验证错误信息传回给前台，结果竟然没有报错！有图有真相：

我捉鸡啊，然后我上网查啊查的，都没有找到原因，倒是有几个Java正则的验证，但是写的像梵文一样的，好长啊，而且几个验证都不一样，感觉不靠谱，还是决定回头来翻看API，看了下SimpleDateFormat类的API也木有看出个啥，顿时有种万念俱灰的感觉，这时候看到SimpleDateFormat有个父类DateFormat，就当再看看说明吧，然后在看DateFormat的API的时候，突然发现DateFormat有个方法setLenient

 顿时感觉有那么一点点靠谱的感觉，然后就抱着试试看的态度试了下，擦，果然靠谱！

只要你把setLenient()里面的参数设成false，那么你当前new出来的这个SimpleDateFormat或者DateFormat就会自动帮你验证你parse里的日期字符串是否符合规范。注意：它默认是宽松的，就是isLenient == true！ 
指定日期/时间解释是否是宽松的。对于宽松的解释，可以将诸如 "February 942, 1996" 之类的日期视为等同于 1996 年 1 月 1 日后的第 941 天。而对于严格的（non-lenient）解释，这样的日期会导致抛出异常。默认情况下是宽松的。（来自API解释，比我那个什么13减12解释的简单明了多了 - -!）
所以我想做的事，现在一句代码就解决了，SimpleDateFormat.setLenient(false)就可以了！虽然就一句代码的事，但是感觉这个毕竟不太常用，也许有些同事像我一样并不太了解这一块，所以写出来给大家一起分享下哈。

现在回过头来想想，通过这么一个小小的问题我总结出来两点小经验：
1. 开发的时候遇到不明白的地方，首先就应该翻开API，API永远是你最可靠的助手。
2. 写代码的时候不要太自信，自信需要来源于自身强大的实力，而我没有。。。（像我一开始连那个Lenient原理都不明白，自以为是会Try catch的，结果被QA测出来了，惭愧。）