Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
Especially since we're not ignoring leap seconds; in UTC, "30 days" is not always 30*86400 atomic seconds. Other units are more obviously variable-length, but you have to be careful. If you increment one month at a time with autocorrect, 4 months from Jan 31 gets you Jun 2 or 3 instead of May 31. On Friday, April 9, 2010, Mark Biggar wrote: > On 4/9/2010 4:53 AM, Moritz Lenz wrote: > > Am 09.04.2010 13:34, schrieb Mark J. Reed: > > 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? > > > Too much magic. Sounds to me like you want a named parameter for a > setter, like :force or :unchecked or so. > > Anyway, I'm not sure such a feature needs to be in the core, at least > not in 6.0.0. > > > Unless forming a duration based on various units is really simple, un-checked > setters makes generating new Instants from one ones simpler. It is very > useful to be able to implement the operators tomorrow, yesterday, > thirty_days_from_now, twelve_hours_ago, etc, just by incrementing through the > appropriate setter, especially in one-liners. > > -- > m...@biggar.org > mark.a.big...@comcast.net > > -- Mark J. Reed
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
On 4/9/2010 4:53 AM, Moritz Lenz wrote: Am 09.04.2010 13:34, schrieb Mark J. Reed: 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? Too much magic. Sounds to me like you want a named parameter for a setter, like :force or :unchecked or so. Anyway, I'm not sure such a feature needs to be in the core, at least not in 6.0.0. Unless forming a duration based on various units is really simple, un-checked setters makes generating new Instants from one ones simpler. It is very useful to be able to implement the operators tomorrow, yesterday, thirty_days_from_now, twelve_hours_ago, etc, just by incrementing through the appropriate setter, especially in one-liners. -- m...@biggar.org mark.a.big...@comcast.net
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
Am 09.04.2010 13:34, schrieb Mark J. Reed: 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? Too much magic. Sounds to me like you want a named parameter for a setter, like :force or :unchecked or so. Anyway, I'm not sure such a feature needs to be in the core, at least not in 6.0.0. Cheers, Moritz
Re: Unchecked versions of the setters (Re: Temporal.pod truncate)
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
Unchecked versions of the setters (Re: Temporal.pod truncate)
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
