Re: [Python-Dev] Status on PEP-431 Timezones
[delightful new insight elided, all summarized by what remains ;-) ] [Tim] What somedatetime+timedelta really does is simpler than that: it adds the number of microseconds represented by the timedelta to somedatetime, [Lennart]] No it doesn't. Lennart, I wrote the code. Both the Python and C datetime implementations. I know exactly what it does, and these repetitive denials can't change that. Well, maybe they can. I really am just assuming they can't ;-) Here's, e.g., the Python code for datetime.__add__: def __add__(self, other): Add a datetime and a timedelta. if not isinstance(other, timedelta): return NotImplemented delta = timedelta(self.toordinal(), hours=self._hour, minutes=self._minute, seconds=self._second, microseconds=self._microsecond) delta += other hour, rem = divmod(delta.seconds, 3600) minute, second = divmod(rem, 60) if 0 delta.days = _MAXORDINAL: return datetime.combine(date.fromordinal(delta.days), time(hour, minute, second, delta.microseconds, tzinfo=self._tzinfo)) raise OverflowError(result out of range) There's not much to it. Apart from the year, month and date parts of `self` (which are converted to an integer number of days), all the rest is just adding integer microseconds expressed in two distinct mixed-radix systems. What part of that inspires your No it doesn't? It quite obviously does, if you understand the code. Your real objection (whether you realize it or not) is that it's not converting to UTC at the start and back to self._tzinfo after. But what does it matter? I'm done with this line. You can get what you want, but it has to (according to me) be done in a backward-compatible way (and see other msgs for ideas in that direction). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
On 28 July 2015 at 05:18, Ben Finney ben+pyt...@benfinney.id.au wrote: Indeed, these non-rational ways of reaching a decision are essential to allow us to act with any kind of speed. Non-rational decision making is much faster, and necessarily will form the great majority of our decision making. Good! What I'm making explicit is: those can't serve as *justification* for introducing a change. When a change is challenged (by someone to whom we are answerable), claiming that it just “felt right” is not enough. But isn't the whole *point* of a non-rational decision (as you describe it) that you *can't* articulate your reasons for making that decision. You can't have your cake and eat it - are core devs allowed to make non-rational judgements or not? (In your view - in mine, they clearly are, and being required to justify those decisions after the fact is *not* acceptable). Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
I was going to jump in and explain the rationale for the original design and why we shouldn't change it, but I just realized that Tim Peters has been explaining this position already, and instead I am going to mute this thread. Please switch to python-ideas or to the new datetime-specific list (if it's ever created -- personally I think it's a waste) and change the subject if you need me to chime in. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
[Ronald Oussoren] I totally agree with that, having worked on applications that had to deal with time a lot and including some where the end of a day was at 4am the following day. That app never had to deal with DST because not only are the transitions at night, the are also during the weekend. [Lennart Regebro] If you don't have to deal with DST, then you don't have to have tzinfo's in your date objects. There are no tzinfos on date objects. I assume Ronald is talking about datetime objects. You can have just truly naive objects without DST information, and this will work just fine. I suspect not at all: Ronald pretty obviously wants to mirror the local clock, he just doesn't care about what happens in the tiny number of cases adjacent to a DST transition buondary, because those boundaries occur at night ... during the weekend, times his app predictably never needed to worry about. I think most people's expectations are that datetime's that *are* time zone aware, should actually deal correctly with those time zones. They almost always do, you know ;-) You want perfection in every case. Others are delighted to trade off perfection in twice a year wee hour on a weekend cases for straightforward move N units in local time local-time arithmetic It might be nice to have time zone aware datetime objects with the right(TM) semantics, but those can and should not replace the naive objects we know and love. Yes, they most certainly should. They can't, at least not before Python 4. Nobody can break over a decade's worth of user code for something so objectively minor. Even in Python 4, you'd still need to get Guido's approval to reject his design, and I doubt he'd be willing (but, of course, I may be wrong about that). There are other, backward-compatible, ways to get what you want (although I don't really see a need: it's a one-line Python function for each kind of tz-perfection-in-all-cases arithmetic you favor). For example, I offhandedly suggested adding a new magic attribute to tzinfo objects; if present, datetime would compute the other kind of arithmetic. Another idea I saw last night was to create a new timedelta-like class, then change datetime's arithmetic to act differently when asked to use an instance of that new class in arithmetic (although, unlike the magic tzinfo attribute, that couldn't affect the behavior of datetime-datetime subtraction). I will try to shut up now, but let me be clear on that the time zone support as it stands now is intentionally broken. Not naive, *broken*. It does indeed intentionally deviate from reality in some cases. All the usecases people have here for supporting naive objects would work just as well if they actually used naive objects, ie datetimes with no timezone info. If you explicitly do NOT want the datetimeobject to care about timezones, then you should not add a timezone to the object. As at the start, I'm sure Ronald does/did care about mirroring local time, including DST. He just doesn't care about what happens at the relative handful of problem times. Lots of apps are similar. Someone yesterday asked for an example of _how_ he could code a cross-timezone app to schedule remote meetings with his students. They need to occur at the same local time (for the student) once per week, and he wanted a 5-minute (something like that) warning before the meeting started in his own time zone. I'm not sure whether anyone answered him yet. This is almost certainly another case where nobody cares what happens _near_ DST transition boundaries (these are humans, so neither side would agree to meet routinely at wee hours on a weekend). So it's all easy to do with Python as it exists: naive arithmetic is exactly what he needs to schedule a series of meetings at the same local times separated by (naive) local weeks. first_meeting_time = datetime(Y, M, D, H, tzinfo=student_timezone) student_times = [first_meeting_time + timedelta(weeks=i) for i in range(NUM_MEETINGS)] my_times = [student_time.astimezone(my_timezone) for student_time in student_times] DST transitions are vital to track on both sides, but no time in use will appear near a transition boundary - naive time is a perfectly adequate approximation, because it agrees with reality at every time the app cares about. And naive datetime arithmetic is the only kind of arithmetic of use here. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
[Lennart Regebro rege...@gmail.com] Of course, I meant datetime objects. In everything else, I stand by my original claim. If you want naive datetime obejcts, you should use naive datetime objects. That's tautological (if you want X, you should use X). I'm not sure what you intended to say. But it's a fact that some apps do need DST-aware datetime objects, and also need naive datetime arithmetic on those objects. The point isn't that there's no way to get the latter if Python datetime arithmetic changed; the point is that it _already works_ for them, and has for 12 years. You can't break apps without overwhelmingly compelling reason(s). Please move on to think about backward-compatible ways to get what you want instead. In the meantime, writing little functions to do the convert/arithmetic/convert dance is the obvious way to get what you want. My opinion is and remains that intentionally breaking datetime arithmetic to make non-naive objects behave in a naive way was a mistake. While other people think it was a fine and useful compromise. It's certainly fortunate that repetition changes minds ;-) Regardless, that decision is ancient history now. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 10:25 AM, Łukasz Rekucki lreku...@gmail.com wrote: Maybe instead of trying to decide who is wrong and which approach is broken, Python just needs a more clear separation between timezone aware objects and naive ones? Well, the separation is pretty clear already. Tim wants to have naive timezone aware objects, ie datetime objects that have a time zone but ignores the time zone, except when converting to other time zones. I have yet to see a use case for that. //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Mon, Jul 27, 2015 at 04:28:48PM -0700, Chris Barker wrote: The only other thing I found really weird about datetime is how Python 2 had no implementation of a UTC tzinfo class, despite this being utterly trivial - Huh? it is either so trivial that there is no point -- simiply say that your datetimes are UTC, and you are done. Or it's not the least bit trivial -- the only difference between a UTC datetime and a naive datetime is that one can be converted to (or interact with) other time zones. Except that, as we know from this conversation, is very, very non-trivial! No, it has nothing to do with conversions. The difference between a naive timezone and a UTC one is that the UTC one explicitly specifies that it's UTC and not local time or some other assumed or unknown timezone. This can make a big difference when passing datetime objects to third-party libraries, such as database interfaces. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters tim.pet...@gmail.com wrote: [Tim] timedelta objects only store days, seconds, and microseconds, [Lennart Regebro rege...@gmail.com] Except that they don't actually store days. They store 24 hour periods, Not really. A timedelta is truly an integer number of microseconds, and that's all. That's what I said. Timedeltas, internally assume that 1 day is 24 hours. Or 8640 microseconds. That's the assumption internally in the timedelta object. The problem with that being that in the real world that's not true. 24 hours is 24 hours at any time in _any_ time zone, ignoring leap seconds. timedeltas are durations, not points in time. time zones make no sense applied to durations. My point exactly. And should not then adding 8640 microseconds to a datetime actually result in a datetime that happens 8640 microseconds later? ie, it assumes that one day is always 24 hours. That's really not what it's doing That is really exactly what the timedelta is doing, as you yourself, just a few lines above say. used in explanations. What somedatetime+timedelta really does is simpler than that: it adds the number of microseconds represented by the timedelta to somedatetime, No it doesn't. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 9:00 AM, Tim Peters tim.pet...@gmail.com wrote: [Lennart Regebro] If you don't have to deal with DST, then you don't have to have tzinfo's in your date objects. There are no tzinfos on date objects. I assume Ronald is talking about datetime objects. Of course, I meant datetime objects. In everything else, I stand by my original claim. If you want naive datetime obejcts, you should use naive datetime objects. My opinion is and remains that intentionally breaking datetime arithmetic to make non-naive objects behave in a naive way was a mistake. //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
Paul Moore p.f.mo...@gmail.com writes: On 28 July 2015 at 13:35, Ben Finney ben+pyt...@benfinney.id.au wrote: People can, do, and probably must make many decisions through non-rational processes. I don't propose to change that. Good. Choices can be made that, when challenged, lack compelling rational justification. I do propose that such a challenge should be taken as a healthy desire to improve Python, not a personal attack. While that is fine, you appear unwilling to accept the possibility that people may not have the time/energy to develop a detailed rational justification for a change that they have made, and demanding that they do so when they are offering the time they do give on a volunteer basis, is what I claim is unacceptable. I've said many times now that's not what I'm advocating. I've made a clear distinction between the need to *be able to* justify a change, versus arbitrary demands to do so by arbitrary members. The latter is what you're arguing against, and of course I agree. I've never advocated that. The issue is not one of your motives in asking for explanations - it's the implication that you are entitled to require others to *provide* those explanations, to whatever level of detail *you* require. Hopefully this repetition is enough: I do not claim any such entitlement. I hope that clarifies my position. Likewise. Thanks for engaging. -- \ “… correct code is great, code that crashes could use | `\ improvement, but incorrect code that doesn’t crash is a | _o__)horrible nightmare.” —Chris Smith, 2008-08-22 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
Terry Reedy writes: On 7/27/2015 11:21 AM, MRAB wrote: Also, if you add one year to 29 February 2016, what date do you get? I believe the 'conventional' answer is 1 March 2017. That is also 1 Mar 2016 + 1 year. 1 March 2017 - 1 year would be 1 Mar 2016. Leap days get cheated. I doubt there is a *single* conventional answer. With respect to *calendar* years, I suspect that more children born on February 29 celebrate their birthdays on February 28 than on March 1. Another angle: I would imagine that a real conversation would go something like A: Let's meet one year from today. B: Today's the 29th, you know. How about the 28th? If it wasn't mentioned, and one arrived on the 28th, and another on the 1st, we'd consider that a comedy, not one person's error of calculation according to conventional rules. I suspect that what you are calling conventional is actually due to observing the cognitive bias called substitution (of a solvable problem for an insoluble one). That is, the problem of computing the date 1 timedelta year later is substituted for the problem of computing the calendar date 1 year later. But that's inappropriate, because these are two different use cases. Calendar time is for coordination, such as birthday parties, and timedelta time is for process control, such as venting nuclear reactors. Of course timedelta can be considered as a calendar by assigning a place and an epoch, and it's convenient to assign one more or less consistent with the consensus calendar in some reasonable place. Eg, UTC as a calendar is approximately the calendar in London. But this is fundamentally arbitrary. Consider the events that define Easter Sunday. In this framework, I suppose one could characterize datetimes as allowing simple calculations with time intervals suitable for people who don't hold meetings at 1:30am and who don't have birthdays or wedding anniversaries on Feb 29, and are not separated from important events by astronomical distances, nor likely to move at speeds greater than 0.01% of the speed of light before the event happens. Ie, almost all of us almost all of the time. I'm completely satisfied by Tim's answers and think almost all is good enough for the stdlib for now. If a separate module that actually succeeds in eliminating the discrepancies between datetime and calendar time as required by coordinating process control time with human requirements for simultaneous presence at meetings, I'd be for including that calendar module in the stdlib, and deprecating datetime. But *elimination* is a high bar, and I think the stdlib would have to be backward-compatible if it fails that criterion (probably by including both modules). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
Hi, As it's very hard to keep up with the pace of this thread, instead of addressing any particular response I would like to add some (hopefully) useful context. While Java was historically known for the worst date/time handling ever (e.g. months starting with 0), in Java 8 a new module was added named javax.time[1]; It contains (amongst others) the following classes: LocalTime (= datetime.time) LocalDate (= datetime.date) LocalDateTime (= datetime.datetime without tzinfo) OffsetDateTime (= datetime.datetime + datetime.timezone) ZonedDateTime (AFAIU equivalent to how Lenart wants the datetime.datetime + IANA timezone to work) Instant (a calendar independent representation of a point in time using UTC-SLS) Duration (= datetime.timedelta) Period (e.g. 1 year, 2 months and 3 days - no real counterpart in Python) (I'm not sure which class would be equivalent to what Tim describes.) While having some Java-style boilerplate, this API is both pure and very practical. Each class serves a bit different purpose and covers different use cases without ambiguity and implicit assertions. Maybe instead of trying to decide who is wrong and which approach is broken, Python just needs a more clear separation between timezone aware objects and naive ones? [1]: https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html Best Reagards, Łukasz Rekucki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
Tres Seaver writes: - From a human's perspective, a day from now is always potentially unambigous, just like a month from now or a year from now, whereas 24 hours from now is never so. I gather you've never been a prof who told a student with aggravated writer's block she had 24 hours to produce a draft, and have her walk in 45 minutes early, apologizing profusely for being 15 minutes late! Humans always have a use case in mind. In *my* mind, I *meant* 24 hours or 84600 seconds (estimating process allocations of 2 hours inadvertant sleeping, 3 hours writing, and 19 hours fussing and/or panicking ;-), while the *student* *interpreted* it as be here with a stack of paper at the same time tomorrow. You can say that's just wordplay (or more precisely, that's a communication problem). AFAICS, one way to view Tim's point (or Guido's point in the original decision) is that it's *always* a communication problem, and that Python should refuse to guess. Since communicating sufficiently accurate information about the mapping from any local time to time in any civil system is always difficult (and impossible in the case of civil times one legislative session or more in the future), Python chose naive time arithmetic and naive time classes to represent it (FVO naive equivalent to what Tim said). In other words, datetime and timedelta implement the only calculations it was feasible to just get it right at the time (and I would say that because of the communication problem the alternative use case is *still* an application problem, not a library problem). Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 28/07/2015 13:35, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: One week == 7 days == 7 * 24 hours Two weeks = 2 * (one week) Right, and that of course is not true in actual reality. I know you are not interested in DST, but with a timezone that has DST, two times a year, the above statement is wrong. Tim asked for my definition of two weeks so I've given it. With respect to that in reality this is true, for me, with my application, making my statement above correct. For my application we could go from GMT to BST and back on successive days throughout the year and it wouldn't make any difference. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 3:17 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Tim asked for my definition of two weeks so I've given it. With respect to that in reality this is true, for me, with my application, making my statement above correct. For my application we could go from GMT to BST and back on successive days throughout the year and it wouldn't make any difference. Right. You want a timezone naive datetime. Your usecase is covered, no problemo. //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 28/07/2015 06:21, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: To me a day is precisely 24 hours, no more, no less. In my mission critical code, which I use to predict my cashflow, I use code such as. timedelta(days=14) Is somebody now going to tell me that this isn't actually two weeks? Yes, I'm telling you that, now. The two claims One day is always precisely 24 hours and 14 days is two weeks are not both true. You have to choose one. You can tell me, but as far as I'm concerned in my application both are true, so I don't have to choose one. (and subsequently) Tim asked for my definition of two weeks so I've given it. With respect to that in reality this is true, for me, with my application, making my statement above correct. For my application we could go from GMT to BST and back on successive days throughout the year and it wouldn't make any difference. When your clocks go from winter time to summer time, there are two possibilities: 1) Your application says days=14 and actually gets 167 or 169 hours 2) Your application says days=14 and ends up with the time changing (Or equivalently if you say days=1 or hours=24 or whatever.) A naive declaration of two weeks later could conceivably mean either. When I schedule my weekly Dungeons Dragons sessions, they are officially based on UTC [1], which means that one session starts 168 hours after the previous one. Currently, they happen when my local clock reads noon; in summer, my local clock will read 1PM. Was it still a week later when it was noon once and 1PM the next time? Conversely, my (also weekly) Thinkful open sessions are scheduled every week at 8AM US Eastern time (America/New_York). For anyone on the Atlantic coast of the US, they will occur every Wednesday and the clock will read 08:00 every time. Sometimes, one will happen 167 hours after the previous one, or 169 hours afterwards. Is that a week later? Your application has to make a choice between these two interpretations. This is a fundamental choice that MUST be made. Trying to pretend that your application doesn't care is like trying to say that Code Page 437 is good enough for all your work, and you can safely assume that one byte is one character is one byte. ChrisA [1] Leap seconds aren't significant, as people are often several minutes early or late, so UTC/UT1/GMT/TIA are all effectively equivalent. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building python 2.7.10 for Windows from source
I got my MSI built, after numerous modifications to the various build scripts. the installed file set bears little resemblance to the official release for the same version, which is a bit of a fail for the Open-source principle, but it seems nobody cares, so I'll split. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 09:36 PM, Tim Peters wrote: So what do _you_ do with datetime arithmetic, Tres? Do you do datetime calculations at all, or just store/retrieve values as-is? If the former, are you disturbed that adding timedelta(hours=24) to an aware datetime object never changes the time components (only the day, and possibly also month, and possibly also year)? If that has disturbed you, did you find a way to accomplish what you wanted instead - or are you still stuck? ;-) Sample use cases: - - Embargo a pre-prepared story until 8:00 AM US/Central next Monday. - - Likewise, but allow it to run for three weeks. - - Create a recurring event which occurs from 7:00 - 9:00 PM US/Eastern on the last Thursday of each month. - - Issue a bid for a commodity lot N days before its expiration date; update that bid (if another bid has occurred) at the same time each day until expiration. - - Mark messages published on a distributed event channel to allow clients to sequence them unambiguously. - - For a given sequence of events: if no subsequent matching event occurs within five calendar days of the last event in the sequence, issue a resolved event, terminating the sequence. - - The same, except define the interval using business days (including applying a user-defined holiday calendar). - - Measure / bucket widgets produced across multiple production lines by quarter / month / day / shift / hour, and generate reports comparing results week-over-week, quarter-over-quarter, etc. In none of those cases involving days was the one day is 24 hours, exactly a sufficient approximation, and none of them could tolerate naive datetimes. Typically, the application used a date interval object (or a recurrence object) which generated date offsets without assuming that a day was 86400 seconds. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVt3ArAAoJEPKpaDSJE9HYfCcP/07RNZY6Vp5wfcR8wnv3Zk/Z 3SgaEWPIG7s8ysqUhcxT/E6pMdgrLDwSm681Ceh8SDFKdvmXIgSO4UXdsHz6X9Ja gffUk1p5m/A1p0GFdcIMN9EHI1Ligtrf/s0gYJ+b0TqiDUW9mpD1xOmQaNK2/eE4 xf3iYSdFgvcqNMlIzQ+AyzP53M9npv78zCqr/LI18mRczMOHENb98jXeWycIMHyV TbHL/cZ///Uj1IqAmydezj4K0biPwUeMsNeqzzuMbDsiVFdZn+rql9N+V4BuzINZ ivmvdEIFdBqFoRcJJyoWsuqaR8GX0i/2LTVgj4Xcustj1Wnh2Aq+2yUNi0DQvjxh Y79QbVPtPyjkzFUh/dZG5hLSAEWxXtbaFsinq1eN+hraBXHAN4sTdUeL1zGV7Pz5 SSQXwe2cabqALzjbpSiLN8gZ3s7DbcVn4uDLsS3L7iyoC5Y51puZut6ui+TmdbgK fG2zvkRNayOyiRa1vymNZsjiM9XYrNABVhuVdM+xgqCe62q+bcUKKVKRIZY1JWq4 Fh0hy9MVPeT51oFuaIAPQJfPKleSLf8xElHZ9M0Gm4PbJDvmr04AjZ7MHWicXsqR pbhlbfIDO8c2Pt7JfjLPGY/0UZi0ZVeJV8bD5EaM3xcn80DLKW9UL+8Yg4h9br59 RURP7/N6S66jAEHfcUFo =3LBp -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 28/07/2015 06:21, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: To me a day is precisely 24 hours, no more, no less. OK. In my mission critical code, which I use to predict my cashflow, I use code such as. timedelta(days=14) Is somebody now going to tell me that this isn't actually two weeks? Yes, I'm telling you that, now. The two claims One day is always precisely 24 hours and 14 days is two weeks are not both true. You have to choose one. //Lennart You can tell me, but as far as I'm concerned in my application both are true, so I don't have to choose one. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: One week == 7 days == 7 * 24 hours Two weeks = 2 * (one week) Right, and that of course is not true in actual reality. I know you are not interested in DST, but with a timezone that has DST, two times a year, the above statement is wrong. As I've said elsewhere I've no interest in DST, at least right here, right now, let alone leap seconds. When I run my cashflow forecast the balance in my bank account one year from today isn't going to be influenced by UK clocks falling back to GMT at the end of October and on to BST at the end of next March. And then you should not use timezoned datetimes, but use naive ones. If you don't care about the timezone, then don't use it. Problem solved. It should be noted here that Python is one of the few languages that actually lets you do that. It's not very common to support time zone naive datetimes. Correct. What I would like to know is how many people are in my position, how many people are in the situation of needing every possible combination of dates, times, daylight saving, local time zone rules and anything else you can think of under the sun, and how many are on the scale somewhere in between these two extremes. There are a few positions. 1. Not caring. datetime supports that as of today. This is probably the most common case. That certainly is the case for me most of the time I need to do something with datetimes. It's usually measuring a few seconds of time or calculating dates. 2. Caring about time zones including DST's. IMO, this is the most common case once you care about time zones. You have several time zones, and you want conversion between them to work, and if you say one hour, you mean one hour. Datetime as of today does not support this, and Tim has declared that it never will, at least not before Python 4 (which amounts to much the same thing). 3. The position of Tim and Guido, which is I want my time zone aware datetimes to ignore the time zone, except when converting to other time zones. I have yet to see a use case for that, and hence I am still not convinced that this position is useful, I think it is only based on misunderstanding. 4. ? Are there more positions, something I have missed? //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
Paul Moore p.f.mo...@gmail.com writes: But isn't the whole *point* of a non-rational decision (as you describe it) that you *can't* articulate your reasons for making that decision. You've conflated the process used to make a decision, with the justifications that support that decision. Those are separate. When I decide to avoid travelling a particular route to work one day, my decision could very likely be made non-rationally. Yet when challenged to say why it's a good choice, the non-rational processes I used to make the decision would rightly be dismissed. I can either present rationally compelling justification for choosing the route I used, or the challenger can rightly dismiss my choice as insufficiently justified. You can't have your cake and eat it - are core devs allowed to make non-rational judgements or not? All humans, core developers included, can and must continue to make most of our decisions in a non-rational manner. That's not the issue. (In your view - in mine, they clearly are, and being required to justify those decisions after the fact is *not* acceptable). I'm unsure what the objection is. The challenge is not to the person to justify themselves; it is to the change made, and what justification there is for it. This distinction is subtle but crucial. What do you imagine is the alternative? That changes which lack rational support should be allowed merely because of the person who made them? People can, do, and probably must make many decisions through non-rational processes. I don't propose to change that. Choices can be made that, when challenged, lack compelling rational justification. I do propose that such a challenge should be taken as a healthy desire to improve Python, not a personal attack. Challenging ideas can be misunderstood as challenging a person's character. That's a mistaken conflation, and I try hard to avoid it; I'd love for all of us to do the same. -- \ “If you don't know what your program is supposed to do, you'd | `\ better not start writing it.” —Edsger W. Dijkstra | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Correct. What I would like to know is how many people are in my position, how many people are in the situation of needing every possible combination of dates, times, daylight saving, local time zone rules and anything else you can think of under the sun, and how many are on the scale somewhere in between these two extremes. I should also point out that this is not about supporting everything under the sun in any form at all. It's about whether the arithmetic on a *time zone aware* date time should use that time zone information, or if the time zone aware datetime should ignore the attached time zone. //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 28/07/2015 03:15, Tim Peters wrote: [Mark Lawrence breamore...@yahoo.co.uk] To me a day is precisely 24 hours, no more, no less. I have no interest in messing about with daylight savings of 30 minutes, one hour, two hours or any other variant that I've not heard about. In my mission critical code, which I use to predict my cashflow, I use code such as. timedelta(days=14) Is somebody now going to tell me that this isn't actually two weeks? Precisely define what two weeks means, and then someone can answer. One week == 7 days == 7 * 24 hours Two weeks = 2 * (one week) The timedelta in question represents precisely 14 24-hours days, and ignores the possibility that some day in there may suffer a leap second. As I've said elsewhere I've no interest in DST, at least right here, right now, let alone leap seconds. When I run my cashflow forecast the balance in my bank account one year from today isn't going to be influenced by UK clocks falling back to GMT at the end of October and on to BST at the end of next March. It remains unclear to me which of those outcomes _you_ consider to be actually 14 days. But my bet is that you like what Python already does here (because tz-naive arithmetic is exactly what _I_ want in all my financial code). Correct. What I would like to know is how many people are in my position, how many people are in the situation of needing every possible combination of dates, times, daylight saving, local time zone rules and anything else you can think of under the sun, and how many are on the scale somewhere in between these two extremes. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 28/07/2015 05:26, Tim Peters wrote: Python's datetime supports microsecond precision. Mere seconds are for wimps ;-) Microseconds are for wimps https://bugs.python.org/issue22117 :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
On 28 July 2015 at 13:35, Ben Finney ben+pyt...@benfinney.id.au wrote: People can, do, and probably must make many decisions through non-rational processes. I don't propose to change that. Good. Choices can be made that, when challenged, lack compelling rational justification. I do propose that such a challenge should be taken as a healthy desire to improve Python, not a personal attack. While that is fine, you appear unwilling to accept the possibility that people may not have the time/energy to develop a detailed rational justification for a change that they have made, and demanding that they do so when they are offering the time they do give on a volunteer basis, is what I claim is unacceptable. Those are separate. When I decide to avoid travelling a particular route to work one day, my decision could very likely be made non-rationally. Would you be happy if someone insisted, when you arrive at work, that you rigorously justify your choice, down to the smallest detail? Why didn't you avoid road A, as there's a bridge over that road and when you go that way you risk the bridge collapsing and killing you? There's no way it makes sense to take such a significant risk when by going down road B you could avoid it, for no more than 10 minutes' delay. As a further point, even if your challenge is from a desire to ensure the best possible outcome for Python, you may not know the subject area as well as the core dev involved (that's pretty much by definition for these mailing list debates). In order to explain the decision, the core dev may need to give you a lot of information that they already know, from experience. Your demand for explanation has now turned into a demand for free education. Is that still acceptable? Must Steve Dower or I explain all of the relevant intricacies of Windows to you just so that you can understand our explanation of why we made a particular Windows-related change? The issue is not one of your motives in asking for explanations - it's the implication that you are entitled to require others to *provide* those explanations, to whatever level of detail *you* require. I hope that clarifies my position. In the spirit of what I've said above, I hope you won't take it the wrong way if I point out that this discussion has become a drain on my limited personal time, and I am no longer finding it of interest. As a result, I'm not going to follow up further. If what I've said doesn't justify my position sufficiently, we'll simply have to agree to differ. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 28/07/2015 07:54, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters tim.pet...@gmail.com wrote: [Tim] timedelta objects only store days, seconds, and microseconds, [Lennart Regebro rege...@gmail.com] Except that they don't actually store days. They store 24 hour periods, Not really. A timedelta is truly an integer number of microseconds, and that's all. That's what I said. Timedeltas, internally assume that 1 day is 24 hours. Or 8640 microseconds. That's the assumption internally in the timedelta object. The problem with that being that in the real world that's not true. In my real world it is. We clearly have parallel worlds. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters tim.pet...@gmail.com wrote: I have yet to see a use case for that. Of course you have. When you address them, you usually dismiss them as calendar operations (IIRC). Those are not usecases for this broken behaviour. 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. I got into this whole mess because I implemented calendars. That use case is the main usecase for those operations. But that usecase is easily handled in several ways. Already today in how datetime works, you have two solutions: The first is to use a time zone naive datetime. 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. But most importantly, there are better ways to solve this that datetime today doesn't support at all: 1. You can use something like dateutil.rrule for repeating events. (works today, but requires a third-party module). 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). 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. 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. Because that's what datetime implements. That's what I want a usecase for. I want the same time next day is not such a usecase. And I don't want that use case for you to convince me that we shouldn't change datetime. You say it breaks too much. OK, if you say so. I don't know. I want to know if that use case actually exists, because I don't think it does. 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. I do think you're missing my fundamental objection: no matter what intended and documented thing datetime (or any other module) has done all along, and regardless of whether I loved it or hated it, I'd be just as annoying about insisting we cannot intentionally break existing code I stopped arguying for changing datetime two days ago. I've also mentioned that several times. 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. //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
Ben Finney writes: I've made a clear distinction between the need to *be able to* justify a change, versus arbitrary demands to do so by arbitrary members. The latter is what you're arguing against, and of course I agree. I've never advocated that. Sure, but the former, when stated as a rule rather than induced from past cases, is also an unacceptably high bar. It's unnecessarily high, because this is open source. No mistake is irrecoverable, even if it happens in a public release. One can always keep using the last release one liked.wink/ Or maintain a local fork. Or switch to a different language. Or gasp/ live with the misfeature. The other face is that it's impossibly high. Some decisions can't be justified rationally, because the theory isn't developed until later, typically based on experience with an intuitively-approved feature. In the end, some decisions really do come down to somebody's gut feeling. As I've already said, in the case of assret I *personally* think the demands of accountability were higher than the mere repetition of it's a minor design decision could satisfy. Nevertheless, I wouldn't try to enunciate a rule. Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
On 29 July 2015 at 00:17, Ben Finney ben+pyt...@benfinney.id.au wrote: I've made a clear distinction between the need to *be able to* justify a change, versus arbitrary demands to do so by arbitrary members. The latter is what you're arguing against, and of course I agree. I've never advocated that. The thing we work toward as core developers, and aspiring core developers, is good design intuition that aligns with the Zen of Python. That doesn't mean we're all going to be able to perfectly *articulate* that intuition in every case, and even when we can, those explanations are themselves generally going to be backed by intuition rather than rigorous scientific research. Perhaps we need a new initialism to summarise these kinds of cases in a way that isn't dismissive of the concerns of folks that still have doubts about a decision: LTIASHIG (Let's Try It And See How It Goes) It's important to remember that *having* good design intuition is a *separate* skill from *explaining* design intuition well. The former involves being able to bring personal experience to bear on a design task, and produce a result that a non-trivial subset of people enjoy using. The latter involves things like learning a lot more about human cognition, and why certain concepts cause the human brain to get jammed up, and how the way a programming language models a particular domain relates to how folks learn about that domain in the first place. One of the best engineers I ever worked for (my first full-time boss) had *brilliant* design instincts, but was substantially weaker when it came to explaining the rationale for his decisions. Spending a few years figuring out why the software architecture he designed was such a good one turned out to be one of the most valuable learning experiences of my life (and, not coincidentally, was my original exposure to the communicating sequential processes approach to concurrency and parallelism). CPython core developers have *real authority* as *individuals* over a language ecosystem used by millions of people. That's a large part of why we're relatively cautious about handing out commit bits - it's not just about the technical aspects, it's about developers' design judgment, and intuitions on when things should be escalated for wider discussion *before* making a decision. Sometimes that intuition is going to tell us this change is worth the risk, even though I can't fully explain why I think that, and hearing further opinions without supporting evidence isn't going to change my mind . Having someone willing to make that kind of call is one of the big reasons modules with an active lead maintainer can more readily evolve than the collectively maintained modules that don't have an authoritative voice guiding their API design. And when we make genuine design mistakes (as we inevitably will)? That's one of the things the deprecation process is for: if a mistake is actively causing problems for folks attempting to use a feature, then we have options to deal with it, rather than having to carry it forever. In many cases, we can even go with a better approach, where changing our minds later involves making a *backwards compatible API change*, reducing the practical long term design risk of postponing a particular aspect of a decision to near zero. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 28/07/2015 16:47, Chris Angelico wrote: On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 28/07/2015 06:21, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: To me a day is precisely 24 hours, no more, no less. In my mission critical code, which I use to predict my cashflow, I use code such as. timedelta(days=14) Is somebody now going to tell me that this isn't actually two weeks? Yes, I'm telling you that, now. The two claims One day is always precisely 24 hours and 14 days is two weeks are not both true. You have to choose one. You can tell me, but as far as I'm concerned in my application both are true, so I don't have to choose one. (and subsequently) Tim asked for my definition of two weeks so I've given it. With respect to that in reality this is true, for me, with my application, making my statement above correct. For my application we could go from GMT to BST and back on successive days throughout the year and it wouldn't make any difference. When your clocks go from winter time to summer time, there are two possibilities: 1) Your application says days=14 and actually gets 167 or 169 hours 2) Your application says days=14 and ends up with the time changing My cashflow forecast doesn't give two hoots how many hours there are in two weeks, which I've defined elsewhere. It doesn't care if the time changes. Neither does it care how many days there are in a month for that matter. It can even cater with plotting data with a tick on the 29th of each month when we have a leap year and February is included in the plot, thanks to the dateutils rrule. (Or equivalently if you say days=1 or hours=24 or whatever.) A naive declaration of two weeks later could conceivably mean either. When I schedule my weekly Dungeons Dragons sessions, they are officially based on UTC [1], which means that one session starts 168 hours after the previous one. Currently, they happen when my local clock reads noon; in summer, my local clock will read 1PM. Was it still a week later when it was noon once and 1PM the next time? Don't know and don't care, your application is not working in the same way that mine does. Conversely, my (also weekly) Thinkful open sessions are scheduled every week at 8AM US Eastern time (America/New_York). For anyone on the Atlantic coast of the US, they will occur every Wednesday and the clock will read 08:00 every time. Sometimes, one will happen 167 hours after the previous one, or 169 hours afterwards. Is that a week later? Ditto my above remark. Your application has to make a choice between these two interpretations. This is a fundamental choice that MUST be made. Trying to pretend that your application doesn't care is like trying to say that Code Page 437 is good enough for all your work, and you can safely assume that one byte is one character is one byte. No. ChrisA [1] Leap seconds aren't significant, as people are often several minutes early or late, so UTC/UT1/GMT/TIA are all effectively equivalent. Precisely my point. For me hours are not significant, days are. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: To me a day is precisely 24 hours, no more, no less. Start with this line. Then proceed: On Wed, Jul 29, 2015 at 3:01 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: My cashflow forecast doesn't give two hoots how many hours there are in two weeks, which I've defined elsewhere. It doesn't care if the time changes. Neither does it care how many days there are in a month for that matter. It can even cater with plotting data with a tick on the 29th of each month when we have a leap year and February is included in the plot, thanks to the dateutils rrule. Okay. So you do *not* care that a day be, or not be, 24 hours. Your code cares about days, and does not care if one of them happens to be 23 or 25 hours long. That's what's going on. To you, a day is *one day*, and has no correlation to 24 hours, 86400 seconds, 86,400,000 milliseconds, or the radiation period of caesium. That's a perfectly acceptable standpoint, but you MUST acknowledge that this is incompatible with the equally-acceptable standpoint that 1 day == 24 hours. You cannot have both. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
On 28 Jul 2015, at 03:13, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 06:11 PM, Ronald Oussoren wrote: Treating time as UTC with conversions at the application edge might be cleaner in some sense, but can make code harder to read for application domain experts. It might be nice to have time zone aware datetime objects with the right(TM) semantics, but those can and should not replace the naive objects we know and love. Interesting. My experience is exactly the opposite: the datetimes which application domain experts cared about *always* needed to be non-naive (zone captured explicitly or from the user's machine and converted to UTC/GMT for storage). As with encoded bytes, allowing a naive instance inside the borders the system was always a time-bomb bug (stuff would blow up at a point far removed from which it was introduced). The instances which could have safely been naive were all logging-related, where the zone was implied by the system's timezone (nearly always UTC). I guess the difference is that I'm usually writing apps whose users can't be presumed to be in any one timezone. Even in those cases, having the logged datetimes be incomparable to user-facing ones would make them less useful. I usually write application used by local users where the timezone is completely irrelevant, including DST. Stuff needs to be done at (say) 8PM, ands that’s 8PM local time. Switching to and from UTC just adds complications. I’m lucky enough that most datetime calculations happen within one work week and therefore never have to cross DST transitions. For longer periods I usually only care about dates, and almost never about the number of seconds between two datetime instances. That makes the naive datetime from the stdlib a very convenient programming model. And I’m in a country that’s small enough to have only one timezone. IMHO Unicode is different in that regard, there the application logic can clearly be expressed as text and the encoding to/from bytes can safely be hidden in the I/O layer. Often the users I deal with can follow the application logic w.r.t. text handling, but have no idea about encodings (but do care about accented characters). With some luck they can provide a sample file that allows me to deduce the encoding that should be used, and most applications are moving to UTF-8. BTW. Note that I’m not saying that a timezone aware datetime is bad, just that they are not always necessary. Ronald ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Datetime SIG created
Thanks Brett :-) I agree that a dedicated mailing list is a good idea. Please stop flooding python-dev and move open discussions to the new mailing list. By the way, I suggest to open multiple threads since multiple topics were discussed in the same thread. So it became difficult to follow the discussion. Victotr 2015-07-28 21:26 GMT+02:00 Brett Cannon bcan...@gmail.com: https://mail.python.org/mailman/listinfo/datetime-sig In the future feel free to redirect date- and time-related discussions to the SIG since datetime stuff requires such a specific domain knowledge that most of us have. I am also looking for people to be admins of the list. If you're willing to admin the list please let me know and I will add you. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Datetime SIG created
https://mail.python.org/mailman/listinfo/datetime-sig In the future feel free to redirect date- and time-related discussions to the SIG since datetime stuff requires such a specific domain knowledge that most of us have. I am also looking for people to be admins of the list. If you're willing to admin the list please let me know and I will add you. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status on PEP-431 Timezones
[Tim] timedelta objects only store days, seconds, and microseconds, [Lennart Regebro rege...@gmail.com] Except that they don't actually store days. They store 24 hour periods, Not really. A timedelta is truly an integer number of microseconds, and that's all. The internal division into days, seconds and microseconds is a mixed-radix scheme designed to make extracting some common units of duration more efficient than by using division on a single long integer all the time. That's an implementation detail, although one that is exposed. which, because of timezones changing, is not the same thing. 24 hours is 24 hours at any time in _any_ time zone, ignoring leap seconds. timedeltas are durations, not points in time. time zones make no sense applied to durations. This is also clearly intended, for example timedelta allows floats, and will convert the fraction into seconds. I suspect I'm missing your meaning here. Have a specific example to illustrate it? For example, are you talking about things like this? timedelta(weeks=0.5) datetime.timedelta(3, 43200) If so, what of it? A week is _defined_ to be 7 days in timedelta, where a day is in turn defined to be 24 hours, where ... until you finally get down to microseconds. None of this has anything to do with points in time or time zones. It's entirely about duration. In the example, a week turns out to be 6048 microseconds. Half of that is 3024 microseconds. Convert that into mixed-radix days-seconds-microseconds representation, and you're left with 3 days and 43200 seconds (with 0 microseconds left over). I don't see anything remarkable about any of that - perhaps you just object to the use of the _word_ day in this context? It's just a word, and there's nothing remarkable either about viewing a duration of a day as being a duration of 24 hours. It's a timedelta - a duration. UTC offsets of any kind have nothing to do with pure durations, they only have to do with points in time. Calling a day 24 hours _in the context_ of a timedelta is not only unobjectionable, calling a day anything else in this entirely zone-free context would be insane ;-) And as you have repeated many times now, the datetime module's arithmetic is naive But only when staying within a single time zone. For example, if dt1 and dt2 have different tzinfo members, dt1 - dt2 acts as if both were converted to UTC first before doing subtraction. Naive time doesn't come into play _across_ time zones, only _within_ a time zone. When mixing time zones, there's no plausible justification for ignoring either of 'em. So they're not ignored then. ie, it assumes that one day is always 24 hours. That's really not what it's doing, although the analogy is sometimes used in explanations. What somedatetime+timedelta really does is simpler than that: it adds the number of microseconds represented by the timedelta to somedatetime, being careful with carries across the assorted time and date components. That's all. There are no assumptions about what any of it means. What it _doesn't_ do is consult the tzinfo member about anything, and _that's_ the true source of your complaints. It so happens that, yes, naive datetime arithmetic does always treat a day as 24 hours (and a week as 7 days, and a minute as 60 seconds, and so on), but not really because it's assuming anything about what days, weeks, etc mean. It's working with microseconds, and it's giving the result you'd get from working on somedatetime.replace(tzinfo=None) instead, except it doesn't actually remove the tzinfo member. The problem with that assumption is that it isn't true. There isn't really an assumption here. Naive time has no concept of time zone, which isn't an assumption so much as a _requirement_ of the design. You can legitimately object that this requirement is at odds with reality in some cases. And that's true: it is. But that's also been known since the start. It's _intentionally_ at odds with reality in some cases, because it was believed that a simpler approximation to reality would be most useful most often to most applications and programmers. And you've heard from some of them here. Note that the same principle is at work in other aspects of datetime's design. For example, the proleptic Gregorian calendar is itself a simplified approximation to reality. In historical terms it's a relatively recent invention, and even now it's not used in much of the world. So what? It does little harm to most applications to pretend that, e.g., 3 March 1012 is a valid Gregorian date, but simplifies their lives, although some obsessed calendar wonk may be outraged by such a bold fiction ;-) It's all a practicality beats purity thing, but weaker than many such things, because in this case _sometimes_ naive arithmetic is _not_ the most practical thing. It has been in every dateime application I ever wrote, but I recognize that's not the universal experience.
Re: [Python-Dev] Status on PEP-431 Timezones
[Łukasz Rekucki lreku...@gmail.com] Maybe instead of trying to decide who is wrong and which approach is broken, Python just needs a more clear separation between timezone aware objects and naive ones? [Lennart Regebro rege...@gmail.com] Well, the separation is pretty clear already. I preemptively ;-) agreed with Lukasz on this: it's downright strange that we have datetime objects the docs call aware that nevertheless _act_ as if they were naive in some cases of arithmetic. That was the intended design, but it is strange in that respect. So it goes. Tim wants to have naive timezone aware objects, ie datetime objects that have a time zone but ignores the time zone, except when converting to other time zones. That's not about what I want. It's what Python _does_. We can't wish away how the language already works. Guido designed it that way (with an enormous amount of public input debate), and I did the vast bulk of the implementations. It so happens I like Guido's design, but none of that ever depended on what Tim wanted datetime to do (except in minor respects, like adding the .replace() and .fromutc() methods, which weren't part of the original design - I made those up based on painful experience with many iterations of ever-changing prototypes - but my role in arithmetic was just to implement the design specs). I have yet to see a use case for that. Of course you have. When you address them, you usually dismiss them as calendar operations (IIRC). In some of those cases, you correctly pointed out that the user could have done as well (based on all they explicitly revealed about their app's requirements) with a naive datetime object. In other cases, you made the same claim but seemingly incorrectly (like any app that needs to track the local clocks across multiple timezones with inter-zone conversions, and also needs to do calendar operations in those timezones, and - unsurprisingly! - uses Python's datetime arithmetic to implement such operations. It's unsurprising they do so because that was always the intended and documented way to do so - and it has always worked for these purposes). 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. I do think you're missing my fundamental objection: no matter what intended and documented thing datetime (or any other module) has done all along, and regardless of whether I loved it or hated it, I'd be just as annoying about insisting we cannot intentionally break existing code using that thing in non-trivial ways without a justification so compelling that I can't recall a case of it ever happening. If Python had been doing Lennart arithmetic all along, and Guido proposed changing to Guido arithmetic in Python 2 and/or Python 3, I'd be equally opposed to his proposal ( despite that I prefer Guido's vision of how datetime arithmetic should work - tough luck - it's too late. And he'd eventually agree. Be like Guido ;-) ). Given Guido's brief message, I'll cut the weasel words, confident that I'm still channeling his intent in this area: major backward-incompatible changes (like altering the meaning of arithmetic using already-existing objects and operations) are not going to happen. It's clear now that he'd even remain opposed to such a change in a hypothetical everything-can-change Python 4, because he still likes his original design. So please move on. New objects, new operations, new functions, new methods, new optional arguments on existing methods, even new modules ... all remain on the table. Changing the meaning of code that some users are perfectly happy with was never really _on_ the table (which would have been made clear before if the PEP had spelled out that changes to the results of arithmetic wouldn't be restricted to a tiny number of annoying-to-everyone-regardless edge cases). Even convincing _everyone_ that it's broken (which will never happen either) wouldn't change one jot of this. Look: 0.1 + 0.1 + 0.1 == 0.3 False That will remain broken forever too (except, perhaps, until Python 4). and despite that it's one of the most frequent of all user complaints. So at worst you're in good company ;-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
