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>