Mark (>):
> I do think that an "unchecked" version of the setters is called for, one
> that silently converts out-of-range values rather than throwing an
> exception. That's not an easy thing to implement outside of the library
> without duplicating all the range-checking code.
Hm, true (it's not an easy thing to implement setting of out-of-range
values outside of the library). But what would it be used for? What's
the advantage of having a "date" corresponding to no actual day?
What I have been considering is something along the lines of
DateTime.is_valid('2010-02-29'), that returns whether constructing
such a DateTime would be legal (in the sense of 'no exceptions
thrown'). It feels comforting to always leave a way for the API
consumer to find things out without resorting to CATCHing exceptions.
// Carl
