\[~ann.campbell.2] I am wondering why not push the idea a little bit further and check the value for the whole API : hours, day of month, etc. Month is a little bit trickier but concept is the same.
\[~nicolas.peru] are you willing to determine when day=31 is appropriate? Ditto Feb 29?
Also, I tested setting date (day) to 32. While while setting month to 12 rolls the date over into the next year, setting day to 32 does not roll the month over. It (bizarrely) stores 32. So I was able to construct and use a Date for 32 Feb 2014.
+1 @Ann to extend the scope of this rule to day and even year fields. Even if this doesn't fail when setting the day to 54 for instance, this is for sure a bug. And for years, we could for instance check that years is not greater than 2100 ?
SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
Date date = new Date();
date.setDate(30);
date.setMonth(1);
date.setYear(70);
date.setHours(1);
date.setMinutes(1);
date.setSeconds(1);
System.out.println(date.getTime());
System.out.println(sdf.format(date));
Date date2 = new Date();
date2.setDate(2);
date2.setMonth(2);
date2.setYear(70);
date2.setHours(1);
date2.setMinutes(1);
date2.setSeconds(1);
System.out.println(date2.getTime());
System.out.println(sdf.format(date2));
----
This, output the following :
----
5184061257
02/03/1970
5184061265
02/03/1970
----
So it rolls out to the next month as expected (30 of feb is 2 of march for non bissextil year) but the idea behind the rule should be to detect cases where you know you will have a rollout (month >11, day<0, day >31, etc... ) to avoid unreadable writing of dates.
For a first implementation I would not try to go and detect cases such as 30 of february.
