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 <m...@biggar.org> 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 <markjr...@gmail.com>
