On Thu, Jul 30, 2015 at 9:03 AM, Tim Peters <[email protected]> wrote:
> "Naive arithmetic" was my neologism, starting in this batch of > messages. The docs don't call the arithmetic anything, or acknowledge > that more than one kind of arithmetic is possible. Which is really something that needs to addressed! > This batch of > messages needed to call it _something_, so I made something up. > Can we just use the Glossary borrowed from Noda? It doesn't define an "arithmetic", but if we need that term, it could be "Period Arithmetic" and "Duration Arithmetic". And I had assumed that your "naive arithmetic" was Duration arithmetic -- i.e. a day is 24 hours, but apparently not. I'm still confused as to how you can: (paraphrasing my understanding of your earlier post): Convert the datetime to a timedelta from year 1 -- add the timedelta -- convert back to a datetime. I suppose it's a failure of mine to understand how datetime uses the tzinfo object, but this description sure sounds to me like you'd get a datetime that really represented 24 hours later, not 23 or 25 (or something else...) Anyway, my current understanding is that the current implementation of datetime and timedelta is "Period Arithmetic", with only Periods defined in units of days (fraction days, down to microsecond resolution). Is that correct? The kind of arithmetic > Python implements is the only kind that delivers correct answers > _within_ the naive time model,. so I've been calling it "naive > arithmetic" - in the sense of "the arithmetic behavior required by the > naive time model". > Sure -- but we really need the docs to clarify what the heck happens when you have a tz-aware datetime. I'd offer to write a patch for the docs, but as you can see, I'm still pretty confused! In any case, while > mixed datetime/timedelta arithmetic supports only a small subset of > what people want in the way of "calendar operations", it is an > exceedingly useful subset on its own, _and_ in implementing fancier > operations. It was a great start. > Well, yes. I was ecstatic when datetime was introduced, and have found it very, very useful since then. However, not for "calendar operations" (Period Arithmetic) , nor for tz-aware datetimes. (because I don't have much need for these) And unfortunately, I think the implementation of timedelta makes it impossible to extend to richer Period Arithmetic -- it fundamentally uses unit sof days, and has no way to encode any other "Period" unit -- i.e. months or years. The implementation could fully support Duration Arithmetic, so it's a bit of shame that that wasn't chosen in the first place. > I also (naively :-) assumed that people interested in strict arithmetic > would > > just keep using the POSIX timestamps used by the time module. > Well, that explains it -- but no, the time module is very limited and painful to use ;-) -- I was all for Datetime, even though my primary use cases are all Duration arithmetic. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected]
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
