On Tue, Jul 28, 2015 at 5:15 PM, Felipe Ochoa <felipe.nospam.ochoa(a)gmail.com
> wrote:
> 1. We cannot break backwards-compatibility (This point has been beaten to
> death)
>
OK then -- then timedelta is NOT going to be fundamentally re-denied as
something else altogether -- good!
> 2. There are valid use-cases for wanting datetimes with and without
> timezone info, and for doing naive and aware math. All 3 legal combinations
> of the two (excluding naive dt with aware deltas :-)) have valid use-cases
>
sure -- but the datetime module does not have to support them all, and they
don't all have to be supported with the same objects.
semantics again -- there is no such thing as naive or aware math -- there
are timespan computations and calendar manipulations....
> 3. [new point] If I'm a new user looking in the library for a solution to
> my problem, my use-case is likely to appear "obviously correct", and I'll
> be shocked if Python doesn't support it
>
True for all possible libraries :-) -- though I suppose we have a special
obligation 'cause we claim that "batteries are included"
> 4. [new point] The non-trivial nature of all 3 possibilities makes it
> advantageous to include in the standard library
>
There are a lot of non-trivial, and fairly common things that are not
included in the stdlib.
But I'm all for including calender manipulations in the stlib -- just not
for altering what timedelta means, and trying to be realistic that that's
actually a big project, with lots of ugly corner cases and API decisions.
And there is nothing about that in the PEP, by the way.
As far as I can see, the PEP is about including ready to go, standard
tzinfo object in the stdlib -- whereas when dateime was introduced, it
provided a mechanism, but no implimentation. This is about providing an
implementation.
A. Keep the current mechanics as-is. `+` and `-` result in "naive" datetime
> arithmetic
>
*sigh* about the wording, but yes.
> B. Implement `.get_offset_time(self, hours, minutes, seconds, ms)` and
> `.compute_duration(self, other_dt)` methods for "aware arithmetic." (I.e.,
> congruent to 'convert to UTC, increment, convert back')
>
what the heck would that mean? the timedeltas already do that -- what they
don't do is calendar maniplutaions -- things like "this same time tomorrow"
-- or tomorrow morning at 7:00am.
Maybe this will help people conceptualize:
timedeltas represent what is measured by a stopwatch.
datetimes represent what is represented by a calendar and a watch.
If you start your stopwatch at a particular date indicated by your
calendar, and particular time indicated by your watch, and run it for 24
hours (one day) you can then look at your calendar and watch and see what
the datetime is -- and if you crossed a DST border, it may not be the
_same_ time on your watch.
And if you start your stopwatch at 2:00pm one day, and look at it again at
2:pm the next day, it will say 24 hours, unless you crossed a DST boundary,
in which case it will say 23 or 25 hours -- but would that surprise anyone?
> C. Come up with a new name (or clearly define naive/aware arithmetic) to
> disambiguate the two
>
sure -- I'll vote to not use the term "aware arithmetic" -- it's not really
arithmetic -- "calendar operations"?
and the datetimes can be naive, but the operation is neither naive nor
aware -- a time span is a time span is a time span....
Another thought here that may help:
you can "encode" a datetime in at least two ways:
1) timespan since an epoch: -- i.e seconds since Jan 1, 1970 00:00. This is
how the datetime object keeps it internally.
2) Calendar time in some calendar and time zone: year, month, day, hour,
min, sec.
The "magic" of the datetime object all happens in the conversion between
the two.
(side note -- timedeltas have no calendar concept at all)
most time math is most easily done in encoding (1) -- that's (one reason)
why it's used most of the time. But if you want to do calendar
manipluations, you are better off working in the calendar encoding -- "two
days from now" is much easier to do there.
So I think when people are thinking about "time zone aware math" what they
really are thinking about is calendar encoded math.
By the way, is anyone proposing to add Calendar manipulations to the stdlib?
I understand that folks want that, and apparently some people got confused
that better time zone support meant that -- but is anyone proposing to do
it?
If anyone is, then it's probably a topic for Python-ideas and an entirely
different PEP.
-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(a)noaa.gov
