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 <cma...@gmail.com> 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 <markjr...@gmail.com>
