The date still corresponds to an actual day.  If I set it to Feb 31, I
should get back Mar 2 or 3 depending on the year.  While I'm having
trouble thinking of a good specific example, it's a capability I've
taken advantage of many times, in holiday calculations, calendar
conversions, and such.  I believe it's Python's datetime module that
has unchecked_* methods for the purpose.

Maybe in p6 the setters could do the correction if the exception is resumed?

On Friday, April 9, 2010, Carl Mäsak <> wrote:
> 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

Mark J. Reed <>

Reply via email to