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 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 ad
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 cal
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 b
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
