Mathieu Bouchard writes:

# > Please tell me this is a bug, not a feature.
# >   t = Time.local(2000,11,31)  # Nov 31, 2000 (nonexistent date)
# >   # t is now Dec 1, 2000 - no errors, no nothing
# > This is v. 1.6.0 on AIX.

IMHO, its a bug.

# This seems normal. Given that the day number is not above 31, there are
# several useful things to do with an invalid date:
# 
# 1. Round down to the last day of the month
# 2. Spill over to next month (feb 31, 2001, becomes mar 3, 2001)
# 3. Treat as 1st of the next month
# 4. Return nil or throw exception

4b) Throw exception.

# Case #2 is how UNIX did it, and it's how POSIX does, and then others 
have
# followed; most practical languages do it like POSIX, and javascript does
# too. =)

What about Java? It's intended use for enterprise applications (among 
other things) makes this a somewhat more interesting case to consider.

But in any case, the relevant question is whether "there's a better way to 
do it" (remember TABWTDI) that is also sufficiently worthwhile.

Back a couple of decades ago when machine cycles and bytes were some 100x+ 
times more expensive, I think it was pretty rare for system calls to check 
the validity of arguments, and when they did, they often did a crude job 
of it. But AFAIK, the general trend since then has been in the opposite 
direction (when feasible or convenient), with the general aim of 
increasing reliability and not letting errors slip by undetected, since 
they may be indicators of larger but as yet undetected problems.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)