Whether the valid value ranges for ``++Date++`` fields start with 0 or 1 varies by field. For instance, month starts at 0, and day of month starts at 1. Enter a date value that goes past the end of the valid range, and the date will roll without error or exception. For instance, enter 12 for month, and you'll get January of the following year.
This rule checks for bad values used in conjunction with ``++java.util.Date++``, ``++java.sql.Date++``, and ``++java.util.Calendar++``. Specifically, values outside of the valid ranges:
\[~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.
=== on 8 Oct 2014, 16:15:36 Ann Campbell wrote:
\[~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.
=== on 10 Oct 2014, 15:08:36 Freddy Mallet wrote:
+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 ?
=== on 10 Oct 2014, 19:12:26 Ann Campbell wrote:
Assigning to you [~nicolas.peru] since I'm waiting for you to get back to me on this.
=== on 13 Oct 2014, 13:13:03 Nicolas Peru wrote:
Ok after a little test :
----
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.
=== on 13 Oct 2014, 15:41:13 Ann Campbell wrote:
Okay, see what you think.
=== on 25 Nov 2014, 20:15:44 Freddy Mallet wrote:
\[~ann.campbell.2] I would activate this rule by default ...
=== on 4 Feb 2015, 08:54:56 Nicolas Peru wrote:
\[~ann.campbell.2] Given the extended scope of the rule the title should be reworked. I put this rule in the backlog of sonar-java 3.0.
