On Thu, Jul 30, 2015 at 8:26 AM, ISAAC J SCHWABACHER <[email protected]> wrote:
> > From: Datetime-SIG <datetime-sig-bounces+ischwabacher= > [email protected]> on behalf of Chris Barker <[email protected]> > > Then there seem to be the big hang-up: people want a way to define > Periods (as defined above) and want to be able to do datetime math with > them. I"m still really confused as to why folks seemed to think "time zone > aware" somehow meant using Peiods rather than Durations for arithmetic, > but there you go. Clearly this is very useful thing to have, but it's NEW > feature, and not covered in the PEP. > > I think you're missing something here. This *isn't* the current > behavior-- adding a 24 hour timedelta (a Duration) to an aware datetime (a > ZonedDateTime) *doesn't* produce an aware datetime corresponding to the > Instant 24 hours after the Instant corresponding to the first datetime; > rather, it produces an aware datetime equal to the first but with its days > field incremented by one. This result corresponds to an Instant that may > be 23 or 25 hours (or some weirder number, in exceptional cases) after the > first Instant. Thank you for stating this so clearly -- and yes, I was totally mistaken! Which is to say, currently, datetime.timedelta behaves neither as a Period > nor as a Duration. In order to use it as a Duration, you need to convert > to UTC before doing arithmetic and convert back after. *That* is what has > people up in arms. > OK -- and now I'm "up in arms" as well -- OK, not the least bit up in arms, but quite disappointed -- a true Duration calculation is a very, very useful thing, and having it on TZ-aware datetimes is a critical need. Given backward compatibility, I guess we can't change the behavior of datetime + timedelta, but we need something that provides the Duration concept. And, frankly, we could really use a proper Period object as well. I"m not sure what you mean by behaves "neither as a Period", but it clearly is missing a lot of nice functionality as a Period -- i.e. a way to express Periods in units other than days (i.e. next year, next months, etc...) Also: The datetime docs are really, really horrible and confusing on this aspect. Combine that and Tim Peter's discussion of the implementation, and it seemed really really obvious (to me) that TimeDelta was a Duration -- there was even a quote along the lines of "datetime and timedelta are really just fancy ways of encoding microseconds). And from the docs (and implementation): """ and days, seconds and microseconds are then normalized so that the representation is unique, with 0 <= microseconds < 1000000 0 <= seconds < 3600*24 (the number of seconds in one day) """ So, in this case, a "day" is always and forever 24 hours is 86400 seconds. really weird that that gets interpreted in a timezone with DST as meaning "a calendar day". So it appears that a timedelta is not a fancy way to encode microseconds, but rather, a fancy way to encode a "Period" in units of days, resolved to microseconds. So: it's clear to me, anyway, that it would be desirable to have a way to do both Period and Duration calculations with TZ aware DT objects. How to get there is beyond me at this point -- almost seems we may need to start over. Sigh. -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/
