[Datetime-SIG] Clearing up terminology

[Chris Barker]

On Thu, Jul 30, 2015 at 8:26 AM, ISAAC J SCHWABACHER <ischwabacher at wisc.edu>
wrote:

> > From: Datetime-SIG <datetime-sig-bounces+ischwabacher=
> wisc.edu at python.org> on behalf of Chris Barker <chris.barker at noaa.gov>
> > 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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150730/2a5ef1b8/attachment.html>