verifying a date is valid based on integer values for year, month and day of month

[lbrtchx]

Say you have a Calendar instance.
..
Calendar Klndr = java.util.Calendar.getInstance();
Klndr.setLenient(false);
Klndr.clear();
Klndr.set(Calendar.YEAR, iYOD);
Klndr.set(Calendar.MONTH, iIxMonth);
Klndr.set(Calendar.DAY_OF_MONTH, iDOD);
..
How could you see if the date was write?
..
I don't see any exceptions being thrown in the class to complain for
invalid dates
..
lbrtchx

 

[Steve W. Jackson]

Say you have a Calendar instance.
.
Calendar Klndr = java.util.Calendar.getInstance();
Klndr.setLenient(false);
Klndr.clear();
Klndr.set(Calendar.YEAR, iYOD);
Klndr.set(Calendar.MONTH, iIxMonth);
Klndr.set(Calendar.DAY_OF_MONTH, iDOD);
.
How could you see if the date was write?
.
I don't see any exceptions being thrown in the class to complain for
invalid dates
.
lbrtchx

If you read the discussion in the Javadocs on Calendar, you might want
to reconsider three separate calls to set() because of potential
interactions between fields. Instead, I suggest using the alternate
method set(year, month, date) to set all three at once. Once that's
done, I suspect that the easiest way to validate your three values is to
then compare each to what's in the Calendar.

Of course, that overlooks your call to setLenient(false) above. The API
says you should get an exception if any of those values is out of bounds
when calling set() for individual fields. But my reading suggests that
doesn't cover all your bases (and I haven't tested it). I think it
means you can't pass 15 for a month, for instance. But what happens
when you pass 30 for a day when you've previously set the month to
February isn't obvious. That's why I think you might be better off
letting it stay lenient, using the set() version that takes all three
values, and then comparing the result against the ones you sent in.

= Steve =