Mailman 3 July 2015 - Datetime-SIG

Re: [Datetime-SIG] Local time disambiguation proposal
by Chris Barker 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 12:40 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > On Thu, Jul 30, 2015 at 3:23 PM, Chris Barker <chris.barker(a)noaa.gov> > wrote: > > But we need to (a) be really clear in the docs whether the flag is > consulted > > any any other time. and (b) probably be really careful in the code to > make > > sure the flag is set appropriately at all times. > > "This member will have the value True for all instances except those > that represent the second (chronologically) moment in time in an > ambiguous case." [1] > > Does this require any more clarification? well, it certainly would if it were named somethign like "is_dst", but in the intereast of abslute calrity, how about we add something like: "This member can not be set to force the DST adjustment to behave any differently than the tzinfo object implements it." and/or "This member is not an indicator of whether DST is currently in effect, but is only an indicator or which offset to use in ambiguous cases." -Chris > If so, can you suggest it? > > [1]: https://github.com/abalkin/ltdf/blob/master/README.rst#the-first-flag > -- 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

1 0

Re: [Datetime-SIG] Clearing up terminology
by Chris Barker 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 12:51 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > I _think_ I've divined the intent now: > > - "classic arithmetic": what Python datetime arithmetic currently does > > - "strict arithmetic": aka timeline arithmetic, what Lennart wants > aka "Duration Arithmetic" > - "human arithmetic" aka "calendar operations" aka "Period Arithmetic" > For example, there "should be" a way to spell "an > hour from now" that follows "strict arithmetic" rules when the > datetime is aware. > > Or not ;-) > well, "should" is a loaded word, but it would be very, very useful (to some of us anyway). I deal with scientific datasets, I NEVER want 86400 seconds later to mean 23 or 25 hours later ;-) -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

1 0

Re: [Datetime-SIG] Clearing up terminology
by Guido van Rossum 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 6:03 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > [Guido] > > ... > > I also never meant the term "naive" to be used for the existing > arithmetic > > rules for tz-aware datetime objects -- I always meant "naive" to refer to > > tz-less datetime objects. > > "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. This batch of > messages needed to call it _something_, so I made something up. > Cool. I missed that one message out of 100s. :-) > The docs do briefly explain the "native time" _model_ (and acknowledge > that more than one kind of model is possible). I assume you meant naive, not native. > 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. > Which is an unfortunate verbal mess, in large part because "naive > arithmetic" is used for _both_ what the docs call "naive objects" and > "aware objects". Then again, calling _anything_ "naive" in the docs > was probably also unfortunate from the start ;-) > It was definitely naive. :-) > > I would prefer something like "classic arithmetic" for tz-aware datetime > objects. > > Read literally, that doesn't make sense to me, and I can't tease out > the intent. That is, calling an object (whatever it is) a kind of > arithmetic (whatever it is) doesn't make sense to me. I had guessed, > that you wanted to call the kind of _arithmetic_ currently implemented > "classic arithmetic". but in the next sentence you seem to want to > call that "human arithmetic": > And yet that is what I meant, i.e., calling the current arithmetic for tz-aware objects classic, because I wanted to avoid naming it naive (because of the aforementioned verbal mess). > > We can then introduce two new terms for different forms of arithmetic: > > "human arithmetic" for the form that can do things like "+ 2 months" in a > > way that (mostly) matches human expectations, and "strict arithmetic" for > > the form that Lennart needs (essentially move a specific number of > seconds > > along UTC). > > Do you really intend that we use all three: "classic arithmetic", > "human arithmetic", and "strict arithmetic"?. If so, I don't grasp > the intended distinction between "classic" and "human".(both seem to > be the same as what I've been calling "naive arithmetic": the > arithmetic Python currently implements for binary arithmetic operators > involving at least one datetime object). > Yes, I meant to introduce human arithmetic as a third form, to support adding e.g. months or years, while classic and strict arithmetic shouldn't. (Since timedelta doesn't keep its days and seconds separated, it's not really a Period, so I think it shouldn't be extended further. And adding months is a requirement for human arithmetic -- e.g. I was called a bad word on Twitter yesterday because timedelta doesn't support months.) > Anyway, because "strict arithmetic" more-or-less literally means > "arithmetic that wholly satisfies the requirements of a given model", > in isolation the phrase leaves the question of _which_ model open. > So, as was suggested later in the thread, I'd prefer "timeline > arithmetic" (and couldn't care less whether it's called "timeline", > "time line", or both). And I'll conveniently overlook that "timeline > arithmetic" on its own leaves open _which_ timeline (naive or > timezone) is intended ;-) > Sure. > > FWIW (not much, we're stuck with it now), my intention with classic > > arithmetic was to approximate human arithmetic, but only for cases that > > didn't require messy heuristics such as "Feb 29, 2016 plus one year" or > "Jan > > 31, 1956 minus 9 months". > > I always viewed the _model_ ("naive time") as primary. Specific > arithmetic requirements (for builtin arithmetic operators) then > necessarily followed from the choice of model. 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. > I agree. :-) > ... > > > I also (naively :-) assumed that people interested in strict arithmetic > would > > just keep using the POSIX timestamps used by the time module. > > > > >> (BTW, historically, early versions of Python datetime had a separate > >> datetime subclass called datetimetz (IIRC), but the final design got > >> rid of this unnecessary complexity.) > > > I don't believe that was ever released, but it's possible we contemplated > > that and even implemented it in an early pure-Python prototype. > > FWIW, IIRC it did exist in an early prototype but was discarded before > it was even halfway implemented. > I stand corrected. My memory seems to be failing -- I also thought there was a datetime PEP, but I guess we avoided the PEP process (even though datetime was added in 2.3, well after PEP 1 was written) because we were all working in the same office. (Or do I misremember that too? :-) -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] Clearing up terminology
by ISAAC J SCHWABACHER 30 Jul '15

30 Jul '15

[Tim] > But, really, it's dead easy to understand what datetime actually does: > its _model_ is "naive time". In naive time, a day _is_ exactly 24 > hours, and not even the _concept_ of "time zone" exists. Everything > (well, almost ;-) ) about how arithmetic works _follows_ from that > view of the world. The only irregularities are due to the lumpy > nature of the Gregorian calendar (leap years, and months with > differing numbers of days). There's no such thing as "time zones" in > the naive time model. > > What endlessly screws some people up is that (almost) all that remains > strictly true for arithmetic on datetime objects that _do_ have a > fully functinoal tzinfo member. They _still_ follow the "naive time" > model. The presence or absence of a tzinfo member makes (almost) no > difference at all to arithmetic. I personally would have preferred > that "aware" datetime objects use strict/timeline arithmetic instead, > but it's not a big deal to me either way. [ijs] I thought I understood what you were saying until now, but through this entire discussion I have been under the impression that you felt the exact opposite of that last sentence (except for the not being a big deal part). > Nothing at all changes about the arithmetic, _except_ when subtracting > two aware datetime objects. Then the subtraction (in effect) converts > both to UTC before subtracting. Because when mixing datetimes from > _different_ "time zones", there's no plausible justification for > considering them to both be in the _same_ "naive time". So in that > specific case, strict/timeline arithmetic is done. And that's the > source of the repeated "(almost)" repetitions earlier. > > Ah, BTW, comparison of two aware dateimes also acts in strict/timeline > fashion. In my head, that's a consequence of how subtraction works, > but not everyone has the benefit of my mental afflictions ;-) So once we have an is_dst bit, what will be the result of tz = timezone('America/Chicago') datetime(2013, 11, 3, 1, 30, tzinfo=tz, is_dst=True) - datetime(2013, 11, 3, 1, 0, tzinfo=tz, is_dst=False) ? How can it be consistent with current behavior and be anything other than timedelta(0, 1800), even though the first time preceded the second? ijs

1 0

Re: [Datetime-SIG] Clearing up terminology
by Tim Peters 30 Jul '15

30 Jul '15

[Tim, to Guido] > Do you really intend that we use all three: "classic arithmetic", > "human arithmetic", and "strict arithmetic"?. If so, I don't grasp > the intended distinction between "classic" and "human".(both seem to > be the same as what I've been calling "naive arithmetic": the > arithmetic Python currently implements for binary arithmetic operators > involving at least one datetime object). I _think_ I've divined the intent now: - "classic arithmetic": what Python datetime arithmetic currently does - "strict arithmetic": aka timeline arithmetic, what Lennart wants - "human arithmetic" aka "calendar operations" - including at least relative deltas involving units (like months and years) which have no fixed meaning in naive time This intersects with "classic arithmetic" (current "datetime +- timedelta"). but unlike those cases of classic arithmetic is intended to cover both the "naive" and "UTC timeline" models of time. For example, there "should be" a way to spell "an hour from now" that follows "strict arithmetic" rules when the datetime is aware. Or not ;-)

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Alexander Belopolsky 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 3:18 PM, Guido van Rossum <guido(a)python.org> wrote: > On Thu, Jul 30, 2015 at 6:31 PM, Tim Peters <tim.peters(a)gmail.com> wrote: >> >> [Guido] >> > ... >> > The road to improvement that I encourage everyone to explore: add an >> > is_dst >> > flag (with a different name) >> >> There is no path whatsoever to "correct in all cases" in its absence, >> so this should be the top priority for those to whom "correct in all >> cases" is their top priority. > > > And that's why I listed it first. :) "first" it is :-) https://github.com/abalkin/ltdf/blob/master/README.rst#the-first-flag

1 0

naive DateTime, aware DateTime, precise DateTIme
by Ethan Furman 30 Jul '15

30 Jul '15

Instead of making a new timedelta object, which, after all, represents exactly what it says, why don't we make a new DateTime and Time that do the duration arithmetic? Anyone who wants that behaviour has to explicitly use the type so there would be no backwards compatibility issues with the existing DateTime, Time, or timedelta objects. -- ~Ethan~

2 1

Re: [Datetime-SIG] Local time disambiguation proposal
by Alexander Belopolsky 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 3:23 PM, Chris Barker <chris.barker(a)noaa.gov> wrote: > But we need to (a) be really clear in the docs whether the flag is consulted > any any other time. and (b) probably be really careful in the code to make > sure the flag is set appropriately at all times. "This member will have the value True for all instances except those that represent the second (chronologically) moment in time in an ambiguous case." [1] Does this require any more clarification? If so, can you suggest it? [1]: https://github.com/abalkin/ltdf/blob/master/README.rst#the-first-flag

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Guido van Rossum 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 6:46 PM, Chris Barker <chris.barker(a)noaa.gov> wrote: > [...] I thought a timedelta was a duration, but I was wrong, it is a > Period in units of days (I think!), and sure it apparently does that right. > Honestly I don't think timedelta cleanly maps to either of those concepts[1]. While it's true that when a timedelta is added to a datetime it behaves like a Period, when timedeltas are added or subtracted they behave more like Durations: adding several timedeltas just results in modding the number of seconds to be in [0, 86400) and assigning the rest to days (e.g. a timedelta of -1 seconds ends up being -1 days and +86399 seconds). So I don't think it can be extended to provide more human time operations. [1] From http://nodatime.org/1.2.x/userguide/concepts.html; Duration is a simple number of ticks, while a Period is a vector of calendar-based units like year, month, etc. -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] Clearing up terminology
by Chris Barker 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 11:40 AM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > You are the third person on this list who saw > > $ TZ=Australia/Melbourne date +"%c%z" > Thu 30 Jul 2015 10:21:18 AM EST+1000 > > and decided that EST is "likely US Eastern Standard Time." And > neither of the following two > facts have stopped you: > > 1. Melbourne is in Australia, not in the US. > 2. The DST is in effect in the Eastern US in July. nor that an offset of +1000 is not, and never was or will be the offset for "US Eastern Standard Time." All good proof that short names for semi timezones is very, very error prone! (despite the fact that I do it all the time when I write) I'm pretty sure the iso 8601 spec only puts offsets in the string -- uttin gboth an offset and a abbreviation seems like trouble to me :-) But we've got a long way to go before we need to bikeshed the __str__ and __repr__ implementations... -CHB -- 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

1 0