Mailman 3 July 2015 - Datetime-SIG

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

30 Jul '15

On Thu, Jul 30, 2015 at 12:43 PM, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > I would like to make a specific proposal ... I posted my proposal on github [1] and made minor changed there. [1]: https://github.com/abalkin/ltdf/blob/master/README.rst

1 0

Re: [Datetime-SIG] Clearing up terminology
by Felipe Ochoa 30 Jul '15

30 Jul '15

I like the terms Period arithmetic and duration arithmetic. In those terms, what we currently have is the following: * "local/naive" datetime (no tzinfo) + timedelta is period arithmetic, where timedelta is a restricted form of period that supports only days, hours, minutes, seconds, and milliseconds. (Which is equivalent to mixed-radix seconds, as Tim has pointed out) * "aware" datetime (with tzinfo) + timedelta is sort of like period arithmetic, though Noda doesn't define this operation. It is equivalent to: 1) remove the tzinfo to get a local/naive dt 2) perform period arithmetic 3) attach the tzinfo again to get an aware dt. I'm fine extending the Noda definition of "period arithmetic" to cover this case I think Guido and others have suggested we add Duration and Period objects which will implement datetime arithmetic just like in Noda. The only difference in our model would be that instead of LocalDateTime vs ZonedDateTime, we have just datetime, with and without tzinfo. I am very much +1 for this idea, and will write up a Duration object in the next couple of days -Felipe On Thursday, July 30, 2015, Chris Barker <chris.barker(a)noaa.gov> wrote: > On Thu, Jul 30, 2015 at 9:03 AM, Tim Peters <tim.peters(a)gmail.com > <javascript:_e(%7B%7D,'cvml','tim.peters(a)gmail.com');>> 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 > > Chris.Barker(a)noaa.gov > <javascript:_e(%7B%7D,'cvml','Chris.Barker(a)noaa.gov');> >

1 0

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

30 Jul '15

On Thu, Jul 30, 2015 at 9:45 AM, Tim Peters <tim.peters(a)gmail.com> wrote: > Oops! Forgot one: > > [Guido] > > ... create new timedelta-ish classes that implement "human" arithmetic > > Note that there's an annoying inelegance here: after > > datetime2 = datetime1 + timedeltaish # or subtraction > > then what does: > > datetime2 - datetime1 > > produce? yup -- with two (or three!) different flavors of a delta, what can you do? > Of course that's never a problem today. If the inelegance is thought > to be unbearable, I suppose new timedelta-ish classes could provide an > explicit class method to subtract datetime instances (yielding "the > right" timedelta-ish object of the class). > Which makes me think -- is it important that there is ONE datetime object, with two delta objects? or should there be two timedelta objects? That might provide a more obvious API -- which kind of arithmetic do you want to do with these? But also, it would open the door to different implementations: for instance, if your primary goal is to support Duration arithmetic, it may make sense to store the datetime in UTC always, and only mess with time zones on I/O. And you may want to store as "microseconds since year 1" directly as well. Of course, easy conversion between the two would be critical. -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] Calendar vs timespan calculations...
by Chris Barker 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 2:25 AM, Guido van Rossum <guido(a)python.org> wrote: > Perhaps the original intent was that "days" means calendar days, and for >> naive datetimes, it turns out to be the same thing, but that is not what >> the implementation does, and given that it supports seconds and >> microseconds, but not months or years, the API is pretty clearly designed >> for timespans, not calendar definitions. >> > > I can assure you that the implementation carefully matches the original > intent. > I apologise -- I'm afraid I've dragged this out more than necessary due to my misunderstanding -- see my other posts if anyone cases about that. > Even if I wouldn't design it that way today (which honestly I haven't > decided whether I would or not) I don't want to change anything about the > observable behavior[1] that would give a different outcome, > of course not. > no matter how much more "correct" you believe a different outcome would be. > There is "correct" and incorrect, but I"m not arguing that anything is incorrect about the current behavior -- 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. The docs sure need clarifying, though. > The road to improvement that I encourage everyone to explore: add an > is_dst flag (with a different name) > +1 absolutely > and create new timedelta-ish classes that implement "human" arithmetic > (similar to what pytz offers) and "strict" arithmetic (similar to > [NJ]odaTime, IIUC). Separately, standardized access in the stdlib to a tz > database (see another thread). > Sounds good to me -- both are very useful, and clearly defining which is which makes lots of sense. > [1] The *implementation* may change, but not in a way that changes > observable behavior, except for the addition of new attributes, parameters > and/or methods. > hmm -- given that, then perhaps timedelta could be extended to do more rich Period arithmetic without breaking the current behavior. But I suppose the new PeriodDelta object would have to be fleshed out first, to see if that's possible. -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] Calendar vs timespan calculations...
by Tim Peters 30 Jul '15

30 Jul '15

Oops! Forgot one: [Guido] > ... create new timedelta-ish classes that implement "human" arithmetic Note that there's an annoying inelegance here: after datetime2 = datetime1 + timedeltaish # or subtraction then what does: datetime2 - datetime1 produce? Knowledge of the _kind_ of timedelta-ish object used to produce datetime2 is long gone, so it may not be the case that datetime2 - datetime1 == timedeltaish or even produce an object of the same class as timedeltaish. Of course that's never a problem today. If the inelegance is thought to be unbearable, I suppose new timedelta-ish classes could provide an explicit class method to subtract datetime instances (yielding "the right" timedelta-ish object of the class).

1 0

Local time disambiguation proposal
by Alexander Belopolsky 30 Jul '15

30 Jul '15

I would like to make a specific proposal on a narrow topic of how to handle ambiguities inherent in representing time instances in common time zones. The following is a rough sketch where I attempted to identify the areas affected by the proposal and outline the proposed changes. ======= Rationale ======= In the most world locations there have been and will be times when local clocks are moved back. In those times intervals are introduced in which local clocks show the same time twice in the same day. In these situations, the information displayed on a local clock (or stored in a Python datetime instance) is insufficient to identify a particular instance in time. The proposed solution is to add a boolean flag to the datetime instances that will distinguish between the two ambiguous times. ======= Proposal ======= The "first" flag ------------------ We propose adding a boolean member called "first" to the instances of datetime.time and datetime.time classes. This member will have the value True for all instances except those that represent the second (chronologically) moment in time in an ambiguous case. Affected APIs ------------------ Attributes ............... Instances of datetime.time and datetime.datetime will get a new boolean attribute called "first." Constructors .................... The __new__ methods of the datetime.time and datetime.datetime classes will get a new keyword-only argument first=True that will control the value of the "first" attribute in the returned instance. Methods ............. The replace() methods methods of the datetime.time and datetime.datetime classes will get a new keyword-only argument first=True that will control the value of the "first" attribute in the returned instance. Affected behaviors ------------------------- Implementations of tzinfo ....................................... Subclasses of datetime.tzinfo will read the values of "first" in utcoffset() and dst() methods and set it appropriately in the instances returned by the fromutc() method. No change to the signatures of these methods is proposed. Pickle size -------------- Pickle sizes for the datetime.datetime and datetime.time objects will not change. The "first" flag will be encoded in the first bit of the byte that currently stores the 4th byte of the datetime.datetime pickle payload or the 1st byte of the datetime.time. In the current implementation [1] these bytes are used to store hour value (0-23) and the first bit is always 0. Note that first=True will be encoded as 0 in the first bit and first=False as 1. (This change only affects pickle format. In C implementation, the "first" member will get a full byte to store the actual boolean value.) Temporal arithmetics ---------------------------- The value of "first" will be ignored in all operations except utcoffset() and dst() methods of tzinfo implementations and __eq__ and __hash__ methods of the datetime.datetime and datetime.time classes. The only methods that will be able to produce nonzero values of "first" are __new__ and replace() methods of the datetime.datetime and datetime.time classes and fromutc() method of some tzinfo implementations. Backward and forward compatibility ----------------------------------------------- This proposal will have no effect on the programs that do not set the "first" flag explicitly or use tzinfo implementations that do. Pickles produced by older programs will remain fully forward compatible. Only datetime/time instances with first=False pickled in the new versions will become unreadable by the older Python versions. Pickles of instances with first=False will remain unchanged. ================== Questions and Answers ================== 1. Why not call the new flag "isdst"? Alice: Bob - let's have a stargazing party at 01:30 AM tomorrow! Bob: Should I presume initially that summer time (for example, Daylight Saving Time) is or is not (respectively) in effect for the specified time? Allice: Huh? Bob: Alice - let's have a stargazing party at 01:30 AM tomorrow! Alice: You know, Bob, 01:30 AM will happen twice tomorrow. Which one do you have in mind? Bob: I did not think about it, but let's pick the first. [1]: https://hg.python.org/cpython/file/d3b20bff9c5d/Include/datetime.h#l17

1 0

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

30 Jul '15

On Thu, Jul 30, 2015 at 9:03 AM, Tim Peters <tim.peters(a)gmail.com> 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 Chris.Barker(a)noaa.gov

1 0

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

30 Jul '15

[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 create new timedelta-ish classes that implement "human" > arithmetic (similar to what pytz offers) This part seems confused to me: beyond wrapping zoneinfo in a pile of tzinfo objects, pytz's secondary thrust appears to be "correct in all cases" involving DST transition times. Doing things like allowing to correctly distinguish between the ambiguous times when DST ends is, if I understand anything of your intent, a case of better implementing "strict time" than of implementing "human time". IOW, to the extent arithmetic in pytz acts like "human time", it inherits that behavior from what Python already does. > and "strict" arithmetic (similar to [NJ]odaTime, IIUC). That sounds right. > Separately, standardized access in the stdlib to a tz database (see another thread). That's pytz's primary thrust. Also part of dateutil's thrust (dateutil leaves Python's arithmetic results entirely alone in all cases, but also supplies many "calendar operations" useful regardless of whether you use _its_ wrapping of zoneinfo and/or Windows registry databases). > [1] The *implementation* may change, but not in a way that changes > observable behavior, except for the addition of new attributes, parameters > and/or methods. I'm afraid that may not be entirely possible. For example, if datetime objects grow a new attribute, (like some spelling of .is_dst) then repr() presumably needs to display it. But I know what you mean ;-)

1 0

Re: [Datetime-SIG] "Use cases" (was Re: [Python-Dev] Status on PEP-431 Timezones)
by Chris Barker 30 Jul '15

30 Jul '15

Is there any disagreement that both Duration and Period (to use the Noda terms) operations have important and common use-cases? Granted, if not, that doesn't tell us anything about what should be supported in the stdlib, but it seems odd to be arguing about something this basic. -Chris On Wed, Jul 29, 2015 at 6:35 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > [moved from python-dev] > > [Lennart Regebro <regebro(a)gmail.com>] > >>> I have yet to see a use case for that. > > [Tim] > >> Of course you have. When you address them, you usually dismiss them > >> as "calendar operations" (IIRC). > > [Lennart] > > Those are not usecases for this broken behaviour. > > Ever get the feeling we use languages that share many words but few > meanings? I do ;-) > > I can tell you what "use case" means to me: task T is a use case for > gimmick G if and only if G can be used straightforwardly to accomplish > T. That's all. By my meaning, you have been shown use cases. > > > I agree there is a usecase for where you want to add one day to an 8am > > datetime, and get 8am the next day. Calling them "date operations" or > > "calendar operations" is not dismissing them. > > In context, "you usually dismiss them" meant you refuse to accept them > as being use cases (dismiss them for that purpose). Which you do. I > had no intent to imply that you, e.g., held such apps in contempt > (which is a possible meaning of "dismiss"), and apologize if it came > across that way. > > > I got into this whole mess because I implemented calendars. That use > > case is the main usecase for those operations. > > By my definition, I certainly agree that mucking with calendars is a > use case for calendar operations (even without knowing precisely what > "calendar operations" means). > > > But that usecase is easily handled in several ways. > > By my definition, the number of ;_possible_ straightforward ways to > accomplish T is irrelevant to whether T is a use case. It's a use > case for all straightforward ways of accomplishing T. > > > Already today in how datetime works, you have two solutions: The first > > is to use a time zone naive datetime. > > That's not a solution at all to the specific kinds of apps I (& > others) sketched before. Those apps _also_ need to keep track of > local times in multiple time zones, and _also_ need to convert times > among those time zones. Their datetime objects need to have fully > capable tzinfo members. They also need to compute simple kinds of > "calendar operations". > > > This is what most people who want to ignore time > > zones should use. The other is to separate the datetime into date and > > time objects and add a day to the date object. > > Same objection. There was never a claim that _all_ applications are > "use cases" for the status quo; the claim was that you were given > _some_ applications that were use cases. > > > But most importantly, there are better ways to solve this that > > datetime today doesn't support at all: > > "There's a better way to solve it" also has no bearing, in my > definition of "use case", on whether a particular T _is_ a "use case" > for G. There are typically many distinct ways to accomplish a given > T; T is typically a use case for many gimmicks. > > > 1. You can use something like dateutil.rrule for repeating events. > > (works today, but requires a third-party module). > > I agree the apps in question are use cases for some dateutil gimmicks. > > > 2. timedelta could not incorrectly pretend that one day is always 24 > > hours, but actually handle days separately, and always increase the > > days when a day is given. (This would however mean we no longer can > > support fractional days). > > This one is too sketchy for me to guess. If the claim is just that > _some_ kind of timedelta variant could be created that would handle > the specific apps in question if arithmetic worked differently _and_ > the implementations of datetime arithmetic were changed to do > something quite different from the new default when given an instance > of that timedelta variant, then sure. Whether that would be a "better > way" is clear as mud without fleshing out a world of details. > > > 3. There could be a datetelta() object that makes operations on dates, > > leaving hours, minuts, seconds and microseconds alone, or something > > like Lubridates Perod and Delta objects, where a Period() essentially > > operates on wall time, and a Duration() operates on real time. > > Don't know anything about those, so no comment. > > In any case, a full-featured "calendar operations" module would (IMO) > be a welcome addition. In effect, the builtin datetime-timedelta > arithmetic makes some kinds of "calendar operations" dead easy, but > they're limited to moving. in naive time, by (in conceptual terms) > linear combinations of days, weeks, and (rarely) hours. > > > So that's not the usecase I'm asking for. I am specifically asking for > > a usecase where I want an object that is timezone aware, but ignores > > the timezone for everything other than conversion to other timezones. > > And, e.g., you've never seen the description of the cross-timezone > meeting-scheduling app? It wasn't brought up by me, but I have > summarized it for you before. It needs fully aware datetime objects > (both to mirror local clocks, and to convert between timezones), and > it needs simple "same local time a week from now" operations. All > very easily done with the status quo (the only "hard part" is getting > the right tzinfo objects to begin with), and so is unquestionably - by > my definition - a use case for doing naive arithmetic on aware > datetimes. Not only "a" use case, but a good one. I can't imagine a > simpler way (for the user) to accomplish what that app needs. > > > Because that's what datetime implements. That's what I want a usecase > > for. > > And you've been given some. I expect you'll disagree, but if you do > I'll let it end with your response. > > > "I want the same time next day" is not such a usecase. > > With just that much In isolation, no, I agree it isn't a _good_ use > case for doing naive arithmetic on an aware datetime object. But > since it _does_ solve the problem, by my definition I'm afraid it does > count as _a_ use case. If, for reasons neither stated nor denied, > that same app not only needs 'same time next day" but also needs "and > then I need to convert same time next day to some other timezone > (e.g., I'm in a hacker network and my payload won't be ready until > same time next day, and then I have to coordinate releasing the > payload with my criminal partners in China). then that's a fine use > case. Yes, I realize there are other ways that can done. Doesn't > change that it's _a_ use case as is. > > >> But it doesn't matter whether you _call_ them "calendar operations", > >> or anything else. What they're called doesn't change any of the > >> high-order bits: they are use cases, they already work, they have > >> worked that way for a dozen years (an eternity in "computer time"), > >> they were always intended to work that way, and the docs have always > >> said they work that way. > > > They only work like that because people have adapted to how datetime > > does things. If datetime had done this properly from the start, it > > would have worked even better. > > Of course people use whatever is most convenient to get the task at hand > done. > > When people are already getting correct results for _their_ purposes, > using obvious (to them) code, in what way(s) would changing the > arithmetic make those apps work better? I mean, of course, the same > apps that are already working fine. > > > ... > > I stopped arguying for changing datetime two days ago. I've also > > mentioned that several times. > > Yet the argument never ends ;-) Seriously, I hope you find a way to > get interested in this again. You have a wealth of experience that's > valuable here! > > >> using that thing in non-trivial ways without a > >> justification so compelling that I can't recall a case of it ever > >> happening. > > > Well, I've seen several of those on Stackoverflow. > > Happy to look at specific examples. In truth, I _do_ recall some, but > not since Python 1.0.0 was released. > > Example: waaaaaaaaaay back when, ints used (an illusion of) > infinitely wide 2's-complement internally, but longs used (an illusion > of) infinitely wide 1's-complement internally. Both were intended and > documented. > > One consequence: if you had a negative integer K and shifted it > right, the value of the result could differ depending on whether > type(K) was int or long. This made nightmares for my code at the > time, because I needed to mix signed ints and signed longs frequently. > Guido changed it (so that all integer types used the 2's-complement > scheme). But despite that Python had only 2(*) users at the time, he > was still cautious and apologetic about it. > > (*) Maybe 3. I used an old script to compute this, but the exact > value got lost due to the "different representations, with visible > consequences, for negative integers of different types" design flaw > ;-) > _______________________________________________ > Datetime-SIG mailing list > Datetime-SIG(a)python.org > https://mail.python.org/mailman/listinfo/datetime-sig > The PSF Code of Conduct applies to this mailing list: > https://www.python.org/psf/codeofconduct/ > -- 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 8:26 AM, ISAAC J SCHWABACHER <ischwabacher(a)wisc.edu> wrote: > > From: Datetime-SIG <datetime-sig-bounces+ischwabacher= > wisc.edu(a)python.org> on behalf of Chris Barker <chris.barker(a)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(a)noaa.gov

1 0