Re: [Python-Dev] Status on PEP-431 Timezones
On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman et...@stoneleaf.us wrote: Lennart, are you saying you would leave naive objects alone, and fix the tz-aware objects only? Naive objects are not broken, so they can't be fixed. Which I guess means yes. :-) //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 07/27/2015 10:47 PM, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman wrote: Lennart, are you saying you would leave naive objects alone, and fix the tz-aware objects only? Naive objects are not broken, so they can't be fixed. Which I guess means yes. :-) Ah, cool! I'm on board with that! So the next question is how much of the current tz-aware datetime's behavior can be changed? -- ~Ethan~ ___ 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, 27 Jul 2015 02:09:19 -0500, Tim Peters tim.pet...@gmail.com wrote: Seriously, try this exercise: how would you code Paul's example if your kind of arithmetic were in use instead? For a start, you have no idea in advance how many hours you may need to add to get to the same local time tomorrow. 24 won't always work Indeed, no _whole_ number of hours may work (according to one source I found, Australia's Lord Howe Island uses a 30-minute DST adjustment). So maybe you don't want to do it by addition. What then? Pick apart the year, month and day components, then simulate naive arithmetic by hand? The point is that there's no _obvious_ way to do it then. I'd personally strip off the tzinfo member, leaving a wholly naive datetime where arithmetic works correctly ;-) , add the day, then attach the original tzinfo member again. I *think* I'd be happy with that solution. I'm not sure if the opinion of a relatively inexperienced timezone user (whose head hurts when thinking about these things) is relevant, but in case it is: My brief experience with pytz is that it gets this all wrong. (Wrong is in quotes because it isn't wrong, it just doesn't match my use cases). If I add a timedelta to a pytz datetime that crosses the DST boundary, IIRC I get something that still claims it is in the previous timezone (which it therefore seemed to me was really a UTC offset), and I have to call 'normalize' to get it to be in the correct timezone (UTC offset). I don't remember what that does to the time, and I have no intuition about it (I just want it to do the naive arithmetic!) This makes no sense to me, since I thought a tzinfo object was supposed to represent the timezone including the DST transitions. I presume this comes from the fact that datetime does naive arithmetic and pytz is trying to paste non-naive arithmetic on top? So, would it be possible to take the timezone database support from pytz, and continue to implement naive-single-zone arithmetic the way Tim proposes, and have it automatically produce the correct UTC offset and UTC-offset-label afterward, without a normalize call? I assumed that was what the PEP was proposing, but I never read it so I can't complain that I was wrong :) I have a feeling that I'm completely misunderstanding things, since tzinfo is still a bit of a mystery to me. Based on this discussion it seems to me that (1) datetime has to/should continue to do naive arithmetic and (2) if you need to do non-naive UTC based calculations (or conversions between timezones) you should be converting to UTC *anyway* (explicit is better than implicit). The addition of the timezone DB would then give us the information to *add* tools that do conversions between time zones c. At Tim says, the issue of disambiguation is separate, and I seem to recall a couple of proposals from the last time this thread went around for dealing with that. --David ___ 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 Jul 27 2015, Lennart Regebro rege...@gmail.com wrote: That you add one hour to it, and the datetime moves forward one hour in actual time? That's doable, but during certain circumstance this may mean that you go from 1AM to 1AM, or from 1AM to 3AM. Or do you expect that adding one hour will increase the hour count with one, ie that the wall time increases with one hour? This may actually leave you with a datetime that does not exist, so that is not something you can consistently do. Apologies for asking yet another dumb question about this, but I have the impression that a lot of other people are struggling with the basics here too. Can you tell us which of the two operations datetime currently implements? And when people talk about explicitly converting to UTC and back, does that mean that if you're (again, with the current implementation) converting to UTC, *then* add the one hour, and then convert back, you get the other operation (that you don't get when you directly add 1 day)? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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 27 July 2015 at 14:59, R. David Murray rdmur...@bitdance.com wrote: I have a feeling that I'm completely misunderstanding things, since tzinfo is still a bit of a mystery to me. You're not the only one :-) I think the following statements are true. If they aren't, I'd appreciate clarification. I'm going to completely ignore leap seconds in the following - I hope that's OK, I don't understand leap seconds *at all* and I don't work in any application areas where they are relevant (to my knowledge) so I feel that for my situation, ignoring them (and being able to) is reasonable. Note that I'm not talking about internal representations - this is purely about user-visible semantics. 1. Naive datetime arithmetic means treating a day as 24 hours, an hour as 60 minutes, etc. Basically base-24/60/60 arithmetic. 2. If you're only working in a single timezone that's defined as UTC or a fixed offset from UTC, naive arithmetic is basically all there is. 3. Converting between (fixed offset) timezones is a separate issue from calculation - but it's nothing more than applying the relevant offsets. 4. Calculations involving 2 different timezones (fixed-offset ones as above) is like any other exercise involving values on different scales. Convert both values to a common scale (in this case, a common timezone) and do the calculation there. Simple enough. 5. The problems all arise *only* with timezones whose UTC offset varies depending on the actual time (e.g., timezones that include the transition to DST and back). Are we OK to this point? This much comprises what I would class as a naive (i.e. 99% of the population ;-)) understanding of datetimes. The stdlib datetime module handles naive datetime values, and fixed-offset timezones, fine, as far as I can see. (I'm not sure that the original implementation included fixed-offset tzinfo objects, but the 3.4 docs say they are there now, so that's fine). Looking at the complicated cases, the only ones I'm actually aware of in practice are the ones that switch to DST and back, so typically have two offsets that differ by an hour, switching between the two at some essentially arbitrary points. If there are other more complex forms of timezone, I'd like to never need to know about them, please ;-) The timezones we're talking about here are things like Europe/London, not GMT or BST (the latter two are fixed-offset). There are two independent issues with complex timezones: 1. Converting to and from them. That's messy because the conversion to UTC needs more information than just the date time (typically, for example, there is a day when 01:45:00 maps to 2 distinct UTC times). This is basically the is_dst bit that Tim discussed in an earlier post. The semantic issue here is that users typically say 01:45 and it never occurs to them to even think about *which* 01:45 they mean. So recovering that extra information is hard (it's like dealing with byte streams where the user didn't provide details of the text encoding used). Once we have the extra information, though, doing conversions is just a matter of applying a set of rules. 2. Arithmetic within a complex timezone. Theoretically, this is simple enough (convert to UTC, do the calculation naively, and convert back). But in practice, that approach doesn't always match user expectations. So you have 2 mutually incompatible semantic options - 1 day after 4pm is 3pm the following day, or adding 1 day adds 25 hours - either is a viable choice, and either will confuse *some* set of users. This, I think, is the one where all the debate is occurring, and the one that makes my head explode. It seems to me that the problem is that for this latter issue, it's the *timedelta* object that's not rich enough. You can't say add 1 day, and by 1 day I mean keep the same time tomorrow as opposed to add 1 day, and by that I mean 24 hours[1]. In some ways, it's actually no different from the issue of adding 1 month to a date (which is equally ill-defined, but people know what they mean to just as great an extent). Python bypasses the latter by not having a timedelta for a month. C (and the time module) bypasses the former by limiting all time offsets to numbers of seconds - datetime gave us a richer timedelta object and hence has extra problems. I don't have any solutions to this final issue. But hopefully the above analysis (assuming it's accurate!) helps clarify what the actual debate is about, for those bystanders like me who are interested in following the discussion. With luck, maybe it also gives the experts an alternative perspective from which to think about the problem - who knows? Paul [1] Well, you can, actually - you say that a timedelta of 1 day means the same time tomorrow and if you want 24 hours, you say 24 hours not 1 day. So timedelta(days=1) != timedelta(hours=24) even though they give the same result for every case except arithmetic involving complex timezones. Is that what Lennart has been trying to say in his
Re: [Python-Dev] Status on PEP-431 Timezones
On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On the other hand, these rare events are not that different from more or less regular DST transitions. You still have either a non-existent or ambiguous local times interval and you can resolve the ambiguity by adding 1 bit of information. The only question is what should we call the flag that will supply that information? IMO, isdst is a wrong name for dealing with the event I described above. While I see your point that isdst is the wrong name in that it doesn't describe what's actually happening in all cases, it is the most well known instance of the issue, and I personally think that using isdst for the other cases makes sense, and that they would disambiguate in the same direction that it would in a dst transition of the same type (clocks forward or backward). ___ 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 10:54:02AM +0200, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore p.f.mo...@gmail.com wrote: I'm confused by your position. If it's 7am on the clock behind me, right now, then how (under the model proposed by the PEP) do I find the datetime value where it will next be 7am on the clock? PEP-431 does not propose to implement calendar operations, and hence does not address that question. To me, Paul's example is a datetime operation: you start with a datetime (7am today), perform arithmetic on it by adding a period of time (one day), and get a datetime as the result (7am tomorrow). To my naive mind, I would have thought of calendar operations to be things like: - print a calendar; - add or remove an appointment; - send, accept or decline an invitation What do you think calendar operations are, and how do they differ from datetime operations? And most importantly, how can we tell them apart? Thanks, -- 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
Am I the only one feeling like this entire thread should be moved to python-ideas at this point? Top-posted from my Windows Phone From: Steven D'Apranomailto:st...@pearwood.info Sent: 7/27/2015 7:14 To: python-dev@python.orgmailto:python-dev@python.org Subject: Re: [Python-Dev] Status on PEP-431 Timezones On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore p.f.mo...@gmail.com wrote: I'm confused by your position. If it's 7am on the clock behind me, right now, then how (under the model proposed by the PEP) do I find the datetime value where it will next be 7am on the clock? PEP-431 does not propose to implement calendar operations, and hence does not address that question. To me, Paul's example is a datetime operation: you start with a datetime (7am today), perform arithmetic on it by adding a period of time (one day), and get a datetime as the result (7am tomorrow). To my naive mind, I would have thought of calendar operations to be things like: - print a calendar; - add or remove an appointment; - send, accept or decline an invitation What do you think calendar operations are, and how do they differ from datetime operations? And most importantly, how can we tell them apart? Thanks, -- 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/steve.dower%40microsoft.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
Re: [Python-Dev] Status on PEP-431 Timezones
On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com wrote: Am I the only one feeling like this entire thread should be moved to python-ideas at this point? Since this is an area where the discussion of implementation details and the discussion of the developer experience can easily end up at cross purposes, I'm wondering if there may be value in actually splitting those two discussions into different venues by creating a datetime-sig, and specifically inviting the pytz and dateutil developers to participate in the SIG as well. The traffic on a similarly niche group like import-sig is only intermittent, but it means that by the time we bring suggestions to python-ideas or python-dev, we've already thrashed out the low level arcana and know that whatever we're proposing *can* be made to work, leaving the core lists to focus on the question of whether or not the change *should* be made. Whether or not to do that would be up to the folks with a specific interest in working with dates and times, though. 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 Tue, Jul 28, 2015 at 12:13 AM, Steven D'Aprano st...@pearwood.info wrote: On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore p.f.mo...@gmail.com wrote: I'm confused by your position. If it's 7am on the clock behind me, right now, then how (under the model proposed by the PEP) do I find the datetime value where it will next be 7am on the clock? PEP-431 does not propose to implement calendar operations, and hence does not address that question. To me, Paul's example is a datetime operation: you start with a datetime (7am today), perform arithmetic on it by adding a period of time (one day), and get a datetime as the result (7am tomorrow). To my naive mind, I would have thought of calendar operations to be things like: - print a calendar; - add or remove an appointment; - send, accept or decline an invitation What do you think calendar operations are, and how do they differ from datetime operations? And most importantly, how can we tell them apart? Concrete example: I meet with my students on a weekly basis, with the scheduled times being defined in the student's timezone. For instance, I might meet with a student every Thursday at 1PM America/Denver. When there's a DST switch in that timezone, our meetings will be either 167 or 169 hours apart. I want a script that waits until five minutes before my next meeting (with anyone) and then plays Let It Go in a randomly-selected language. How would I go about doing this with pytz and/or datetime? How would I do this under the new proposal? (FWIW, I currently have exactly such a script, but it's backed by my Google Calendar. I'm seriously considering rewriting it to use a simple text file as its primary source, in which case my options are Python (datetime+pytz) and Pike (built-in Calendar module). This does not strike me as an altogether unusual kind of script to write.) And no, Steve, you're not the only one. But maybe the entire thread should completely halt until there's a PEP draft to discuss, and *then* reopen on -ideas. 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 Mon, Jul 27, 2015 at 4:27 PM, Steve Dower steve.do...@microsoft.com wrote: Am I the only one feeling like this entire thread should be moved to python-ideas at this point? Well, there isn't any idea to discuss. :-) It's just an explanation of the problem space. Perhaps it should be moved somewhere else though. ___ 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
Thanks, that got me a bit further. Now I'm wondering how I figure out which version of tcl,tk and Tix actually got built with the 2.7.10 installer. Tools\buildbot\external.bat conflicts with the versions found in PC\build_tkinter.py, and the version in PC\VS8.0\build_tkinter.py. I am assuming the buildbot script is the one that's actually, used? I would submit a patch to clean some of this up, but sounds as though it's in the pipeline. On Fri, Jul 24, 2015 at 2:46 PM, Zachary Ware zachary.ware+py...@gmail.com wrote: On Jul 24, 2015 8:30 AM, Mark Kelley keee...@gmail.com wrote: I have been using Python for some time but it's been a decade since I've tried to build it from source, back in the 2.4 days. Things seem to have gotten a little more complicated now. I've read through the PCBuild/README file and got most stuff compiling. I find it a little odd that there are special instructions for the building the release version of tcl/tk. Is that what the developers actually do when they cut a release, or is there some other, top-level script that does this automatically? It just seems odd. That used to be standard procedure, yes. However, I just recently backported the project files from 3.5, which include project files for building Tcl/Tk and Tix, in both Debug and Release configurations, so I may have missed some stuff that could be removed from PCbuild/readme.txt. You do need some extra stuff to build 2.7 with its new project files, though (which i know is now covered in readme.txt). There hasn't been a release with those project files yet though, they're just in the hg repo. Anyhow, my specific question is around the distutils wininst stubs, provided as binaries in the release tarball. Where can I find the source files that those binaries are built from? I believe the source for those is in PC/bdist_wininst/, or some very similar path. Hope this helps, -- Zach (On a phone) ___ 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 5:12 PM, Paul Moore p.f.mo...@gmail.com wrote: Does thinking of the problem in terms of timedeltas not containing enough information to make a_time + a_timedelta a well-defined operation if a_time uses a non-fixed-offset timezone, make it any easier to find a way forward? Well, I think it is a well-defined operation, but that datetime currently does it wrongly, to be honest. Adding 3600 seconds to a datetime should move that datetime 3600 seconds forward at all time. I just do not see a usecase for doing anything else, to be honest. But if somebody has one, I'm all ears. The problem here is that the issue of get the next day has been mixed into timedeltas, when it in my opinion is an entirely different issue that should be kept separate from timedeltas. It is possible to implement something so that you can both have realtimedeltas and walltimedeltas where adding one hour might give you two hours (or an error) but as per above I can't think of a usecase. //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 2015-07-27 15:59, Paul Moore wrote: On 27 July 2015 at 14:59, R. David Murray rdmur...@bitdance.com wrote: I have a feeling that I'm completely misunderstanding things, since tzinfo is still a bit of a mystery to me. You're not the only one :-) I think the following statements are true. If they aren't, I'd appreciate clarification. I'm going to completely ignore leap seconds in the following - I hope that's OK, I don't understand leap seconds *at all* and I don't work in any application areas where they are relevant (to my knowledge) so I feel that for my situation, ignoring them (and being able to) is reasonable. Note that I'm not talking about internal representations - this is purely about user-visible semantics. Would it help if it was explicit and we had LocalDateTime and UTCDateTime? 1. Naive datetime arithmetic means treating a day as 24 hours, an hour as 60 minutes, etc. Basically base-24/60/60 arithmetic. 2. If you're only working in a single timezone that's defined as UTC or a fixed offset from UTC, naive arithmetic is basically all there is. 3. Converting between (fixed offset) timezones is a separate issue from calculation - but it's nothing more than applying the relevant offsets. 4. Calculations involving 2 different timezones (fixed-offset ones as above) is like any other exercise involving values on different scales. Convert both values to a common scale (in this case, a common timezone) and do the calculation there. Simple enough. 5. The problems all arise *only* with timezones whose UTC offset varies depending on the actual time (e.g., timezones that include the transition to DST and back). Are we OK to this point? This much comprises what I would class as a naive (i.e. 99% of the population ;-)) understanding of datetimes. The stdlib datetime module handles naive datetime values, and fixed-offset timezones, fine, as far as I can see. (I'm not sure that the original implementation included fixed-offset tzinfo objects, but the 3.4 docs say they are there now, so that's fine). Looking at the complicated cases, the only ones I'm actually aware of in practice are the ones that switch to DST and back, so typically have two offsets that differ by an hour, switching between the two at some essentially arbitrary points. If there are other more complex forms of timezone, I'd like to never need to know about them, please ;-) The timezones we're talking about here are things like Europe/London, not GMT or BST (the latter two are fixed-offset). There are two independent issues with complex timezones: 1. Converting to and from them. That's messy because the conversion to UTC needs more information than just the date time (typically, for example, there is a day when 01:45:00 maps to 2 distinct UTC times). This is basically the is_dst bit that Tim discussed in an earlier post. The semantic issue here is that users typically say 01:45 and it never occurs to them to even think about *which* 01:45 they mean. So recovering that extra information is hard (it's like dealing with byte streams where the user didn't provide details of the text encoding used). Once we have the extra information, though, doing conversions is just a matter of applying a set of rules. 2. Arithmetic within a complex timezone. Theoretically, this is simple enough (convert to UTC, do the calculation naively, and convert back). But in practice, that approach doesn't always match user expectations. So you have 2 mutually incompatible semantic options - 1 day after 4pm is 3pm the following day, or adding 1 day adds 25 hours - either is a viable choice, and either will confuse *some* set of users. This, I think, is the one where all the debate is occurring, and the one that makes my head explode. It seems to me that the problem is that for this latter issue, it's the *timedelta* object that's not rich enough. You can't say add 1 day, and by 1 day I mean keep the same time tomorrow as opposed to add 1 day, and by that I mean 24 hours[1]. In some ways, it's actually no different from the issue of adding 1 month to a date (which is equally ill-defined, but people know what they mean to just as great an extent). Python bypasses the latter by not having a timedelta for a month. C (and the time module) bypasses the former by limiting all time offsets to numbers of seconds - datetime gave us a richer timedelta object and hence has extra problems. I don't have any solutions to this final issue. But hopefully the above analysis (assuming it's accurate!) helps clarify what the actual debate is about, for those bystanders like me who are interested in following the discussion. With luck, maybe it also gives the experts an alternative perspective from which to think about the problem - who knows? Paul [1] Well, you can, actually - you say that a timedelta of 1 day means the same time tomorrow and if you want 24 hours, you say 24 hours not 1 day. So timedelta(days=1) != timedelta(hours=24) even though they give the same
Re: [Python-Dev] Status on PEP-431 Timezones
On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano st...@pearwood.info wrote: To me, Paul's example is a datetime operation: you start with a datetime (7am today), perform arithmetic on it by adding a period of time (one day), and get a datetime as the result (7am tomorrow). Well, OK, let's propose these wordings: It looks like a date operation, ie, add one to the date, but in reality it's a time operation, ie add 86400 seconds to the time. These things sound similar but are very different. I called it a calendar operation, because these operation include such things as add one year, where you expect to get the 27th of July 2016, but you will get the 26th if you use a timedelta, because 2016 is a leap year. So we need to separate date (or calendar) operations from time operations. The same thing goes with months, add 30 days, and you'll sometimes get the same result as if you add one month and sometimes not. timedelta adds time, not days, month or years. Except when you cross a DST border where it suddenly, surprisingly and intentionally may add more or less time than you told it to. //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 Jul 27, 2015, at 9:13 AM, Steven D'Aprano st...@pearwood.info wrote: On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore p.f.mo...@gmail.com wrote: I'm confused by your position. If it's 7am on the clock behind me, right now, then how (under the model proposed by the PEP) do I find the datetime value where it will next be 7am on the clock? PEP-431 does not propose to implement calendar operations, and hence does not address that question. To me, Paul's example is a datetime operation: you start with a datetime (7am today), perform arithmetic on it by adding a period of time (one day), and get a datetime as the result (7am tomorrow). To my naive mind, I would have thought of calendar operations to be things like: - print a calendar; - add or remove an appointment; - send, accept or decline an invitation What do you think calendar operations are, and how do they differ from datetime operations? And most importantly, how can we tell them apart? The way I interpreted it is that calendar operations require knowledge of events like daylight savings time that require a more complete knowledge of the calendar, rather than just a naive notion of what a date and time are. ___ 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 3:59 PM, R. David Murray rdmur...@bitdance.com wrote: I'm not sure if the opinion of a relatively inexperienced timezone user (whose head hurts when thinking about these things) is relevant, but in case it is: My brief experience with pytz is that it gets this all wrong. (Wrong is in quotes because it isn't wrong, it just doesn't match my use cases). If I add a timedelta to a pytz datetime that crosses the DST boundary, IIRC I get something that still claims it is in the previous timezone (which it therefore seemed to me was really a UTC offset), and I have to call 'normalize' to get it to be in the correct timezone (UTC offset). Right. I don't remember what that does to the time, and I have no intuition about it (I just want it to do the naive arithmetic!) But what is it that you expect? That you add one hour to it, and the datetime moves forward one hour in actual time? That's doable, but during certain circumstance this may mean that you go from 1AM to 1AM, or from 1AM to 3AM. Or do you expect that adding one hour will increase the hour count with one, ie that the wall time increases with one hour? This may actually leave you with a datetime that does not exist, so that is not something you can consistently do. Dates and times are tricky, and especially with DST it is simply possible to make an implementation that is intuitive in all cases to those who don't know about the problems. What we should aim for is an implementation that is easy to understand and hard to make errors with. This makes no sense to me, since I thought a tzinfo object was supposed to represent the timezone including the DST transitions. I presume this comes from the fact that datetime does naive arithmetic and pytz is trying to paste non-naive arithmetic on top? Exactly. So, would it be possible to take the timezone database support from pytz, and continue to implement naive-single-zone arithmetic the way Tim proposes, and have it automatically produce the correct UTC offset and UTC-offset-label afterward, without a normalize call? That depends on your definition of correct. //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 27 July 2015 at 15:37, Lennart Regebro rege...@gmail.com wrote: That you add one hour to it, and the datetime moves forward one hour in actual time? That's doable, but during certain circumstance this may mean that you go from 1AM to 1AM, or from 1AM to 3AM. Or do you expect that adding one hour will increase the hour count with one, ie that the wall time increases with one hour? This may actually leave you with a datetime that does not exist, so that is not something you can consistently do. OK, that pretty much validates what I thought might be the case at the end of my recent lengthy email. What you're saying is that the idea of a timedelta is insufficiently rich here - just saying 1 hour doesn't give you enough information to know which of the two expectations the user has. (The fact that one of those expectations isn't viable is not actually relevant here). OK, I see what your point is now. No idea how to solve it, but at least I understand what you're getting at (I think). Thanks for not giving up on the thread! Does thinking of the problem in terms of timedeltas not containing enough information to make a_time + a_timedelta a well-defined operation if a_time uses a non-fixed-offset timezone, make it any easier to find a way forward? 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 2015-07-27 15:46, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano st...@pearwood.info wrote: To me, Paul's example is a datetime operation: you start with a datetime (7am today), perform arithmetic on it by adding a period of time (one day), and get a datetime as the result (7am tomorrow). Well, OK, let's propose these wordings: It looks like a date operation, ie, add one to the date, but in reality it's a time operation, ie add 86400 seconds to the time. These things sound similar but are very different. I called it a calendar operation, because these operation include such things as add one year, where you expect to get the 27th of July 2016, but you will get the 26th if you use a timedelta, because 2016 is a leap year. So we need to separate date (or calendar) operations from time operations. The same thing goes with months, add 30 days, and you'll sometimes get the same result as if you add one month and sometimes not. Also, if you add one year to 29 February 2016, what date do you get? timedelta adds time, not days, month or years. Except when you cross a DST border where it suddenly, surprisingly and intentionally may add more or less time than you told it to. ___ 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 10:59 AM, Paul Moore p.f.mo...@gmail.com wrote: The semantic issue here is that users typically say 01:45 and it never occurs to them to even think about *which* 01:45 they mean. So recovering that extra information is hard (it's like dealing with byte streams where the user didn't provide details of the text encoding used). Once we have the extra information, though, doing conversions is just a matter of applying a set of rules. It is slightly more complicated than that. There are locations (even in the US, I've heard) where clocks have been moved back for reasons other than DST. I described one such example in my earlier post [1]. On July 1, 1990, at 2AM, the people of Ukraine celebrated their newly acquired independence by moving their clocks back to 1AM thus living through 1990-07-01T01:45 local time twice. This happened in the middle of summer and daylight savings time was in effect before and after the transition, so you cannot use isdst to disambiguate between the first and the second 01:45. On the other hand, these rare events are not that different from more or less regular DST transitions. You still have either a non-existent or ambiguous local times interval and you can resolve the ambiguity by adding 1 bit of information. The only question is what should we call the flag that will supply that information? IMO, isdst is a wrong name for dealing with the event I described above. [1]: https://mail.python.org/pipermail/python-dev/2015-April/139099.html ___ 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 11:42 AM, Ryan Hiebert r...@ryanhiebert.com wrote: On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On the other hand, these rare events are not that different from more or less regular DST transitions. You still have either a non-existent or ambiguous local times interval and you can resolve the ambiguity by adding 1 bit of information. The only question is what should we call the flag that will supply that information? IMO, isdst is a wrong name for dealing with the event I described above. While I see your point that isdst is the wrong name in that it doesn't describe what's actually happening in all cases, it is the most well known instance of the issue, and I personally think that using isdst for the other cases makes sense, and that they would disambiguate in the same direction that it would in a dst transition of the same type (clocks forward or backward). Well, my specific proposal in [1] was to also change the semantics. The proposed which flag would have the following meaning: 1. If local time is valid and unambiguous, which is ignored. 2. If local time is ambiguous, which=0 means the first and which=1 means the second (chronologically). 3. If local time is invalid, which=0 means the time extrapolated from before the transition and which = 1 means the time extrapolated from after the transition. Note that these rules have some nice properties: if t is ambiguous, UTC(t, which=0) UTC(t, which=1) and if t is invalid, UTC(t, which=0) UTC(t, which=1). This property can be used to take different actions in those cases. The result for ambiguous t and which=0 has a natural interpretation as time specified by a user not aware of the clock change. I think these rules are simpler and more natural than those for isdst which takes 3 values: 0, 1 and -1 and the rules for -1 vary between implementations. Under my proposal unspecified which means which=0. [1]: https://mail.python.org/pipermail/python-dev/2015-April/139099.html ___ 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 4:45 PM, Nick Coghlan ncogh...@gmail.com wrote: On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com wrote: Am I the only one feeling like this entire thread should be moved to python-ideas at this point? Since this is an area where the discussion of implementation details and the discussion of the developer experience can easily end up at cross purposes, I'm wondering if there may be value in actually splitting those two discussions into different venues by creating a datetime-sig, and specifically inviting the pytz and dateutil developers to participate in the SIG as well. +1 for that. ___ 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, 27 Jul 2015 16:37:47 +0200, Lennart Regebro rege...@gmail.com wrote: On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray rdmur...@bitdance.com wrote: I don't remember what that does to the time, and I have no intuition about it (I just want it to do the naive arithmetic!) But what is it that you expect? I just want it to do the naive arithmetic So, would it be possible to take the timezone database support from pytz, and continue to implement naive-single-zone arithmetic the way Tim proposes, and have it automatically produce the correct UTC offset and UTC-offset-label afterward, without a normalize call? That depends on your definition of correct. If I have a time X on date Y in timezone Z, it is either this UTC offset or that UTC offset, depending on what the politicians decided. Couple that with naive arithmetic, and I think you have something easily understandable from the end user perspective, and useful for a wide variety (but far from all) use cases. I'll stop now :) --David ___ 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 27 July 2015 at 16:26, MRAB pyt...@mrabarnett.plus.com wrote: Note that I'm not talking about internal representations - this is purely about user-visible semantics. Would it help if it was explicit and we had LocalDateTime and UTCDateTime? I don't see how. Why should I care about the internal representation? 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 Mon, Jul 27, 2015 at 12:15 PM, Nikolaus Rath nikol...@rath.org wrote: On Jul 27 2015, Lennart Regebro rege...@gmail.com wrote: That you add one hour to it, and the datetime moves forward one hour in actual time? That's doable, but during certain circumstance this may mean that you go from 1AM to 1AM, or from 1AM to 3AM. Or do you expect that adding one hour will increase the hour count with one, ie that the wall time increases with one hour? This may actually leave you with a datetime that does not exist, so that is not something you can consistently do. Apologies for asking yet another dumb question about this, but I have the impression that a lot of other people are struggling with the basics here too. I believe your questions are addressed to Lennart, but let me offer my answer to the first: Can you tell us which of the two operations datetime currently implements? The first one, but not as directly as one might wish. (I think the situation is similar to that of pytz's normalize(), but I am not an expert on pytz.) t = datetime(2014,11,2,5,tzinfo=timezone.utc).astimezone() t.strftime(%D %T%z %Z) '11/02/14 01:00:00-0400 EDT' (t+timedelta(hours=1)).astimezone().strftime(%D %T%z %Z) '11/02/14 01:00:00-0500 EST' ___ 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 27 July 2015 at 15:57, Ronald Oussoren ronaldousso...@mac.com wrote: IMHO “+ 1 days” and “+ 24 hours” are two different things. Date arithmetic is full of messy things like that. “+ 1 month” is another example of that (which the datetime module punts completely and can be a source of endless bikeshidding). Precisely. 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 27/07/2015 15:45, Nick Coghlan wrote: On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com wrote: Am I the only one feeling like this entire thread should be moved to python-ideas at this point? Since this is an area where the discussion of implementation details and the discussion of the developer experience can easily end up at cross purposes, I'm wondering if there may be value in actually splitting those two discussions into different venues by creating a datetime-sig, and specifically inviting the pytz and dateutil developers to participate in the SIG as well. The traffic on a similarly niche group like import-sig is only intermittent, but it means that by the time we bring suggestions to python-ideas or python-dev, we've already thrashed out the low level arcana and know that whatever we're proposing *can* be made to work, leaving the core lists to focus on the question of whether or not the change *should* be made. Whether or not to do that would be up to the folks with a specific interest in working with dates and times, though. Cheers, Nick. Would it be worth doing a straw poll to gauge how many people really need this, from my perspective anyway, level of complexity? I've used datetimes a lot, but I don't even need naive timezones, completely dumb suits me. Alternatively just go ahead, knowing that if the proposal isn't accepted into the stdlib it can at least go on pypi. -- 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 Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath nikol...@rath.org wrote: On Jul 27 2015, Lennart Regebro rege...@gmail.com wrote: That you add one hour to it, and the datetime moves forward one hour in actual time? That's doable, but during certain circumstance this may mean that you go from 1AM to 1AM, or from 1AM to 3AM. Or do you expect that adding one hour will increase the hour count with one, ie that the wall time increases with one hour? This may actually leave you with a datetime that does not exist, so that is not something you can consistently do. Apologies for asking yet another dumb question about this, but I have the impression that a lot of other people are struggling with the basics here too. Can you tell us which of the two operations datetime currently implements? It's intended that the first one is implemented, meaning that datetime.now() + timedelta(hours=24) can result in a datetime somewhere between 23 and 25 hours into the future. Or well, any amount, in theory, I guess some changes are more than an hour, but that's very unusual. And when people talk about explicitly converting to UTC and back, does that mean that if you're (again, with the current implementation) converting to UTC, *then* add the one hour, and then convert back, you get the other operation (that you don't get when you directly add 1 day)? Yes, exactly. //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] Burning down the backlog.
On 7/26/15 6:37 PM, R. David Murray wrote: On Sun, 26 Jul 2015 22:59:51 +0100, Paul Moore p.f.mo...@gmail.com wrote: On 26 July 2015 at 16:39, Berker PeksaÄŸ berker.pek...@gmail.com wrote: So, I'm hoping Carol will take what I've written above and turn it into updates for the devguide (assuming no one disagrees with what I've said :) David, I'm happy to try to incorporate your detailed steps into the devguide. ___ 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 12:57 AM, Ronald Oussoren ronaldousso...@mac.com wrote: IMHO “+ 1 days” and “+ 24 hours” are two different things. Date arithmetic is full of messy things like that. “+ 1 month” is another example of that (which the datetime module punts completely and can be a source of endless bikeshidding). https://www.youtube.com/watch?v=ppfpa5XgZHI MATLAB defines + 1 month as, if I'm not mistaken, add the time it would take to go from the beginning of time to the beginning of January of the year 0 (which is totally a thing, by the way). I'm fairly sure that this is the most WAT-worthy definition possible, as it means that adding one month does nothing, and adding two months adds the length of January (31 days)... and adding three months adds January + February, *in a leap year*. But I agree that adding days and adding hours are different things. If I add one day, I expect that the time portion should not change, in the given timezone. (With the exception that DST switches might mean that that time doesn't exist.) If I add 86400 seconds, I expect that it should add 86400 ISO seconds to the time period, which might not be the same thing. If you convert a datetime to a different timezone, add 86400 seconds, and convert back to the original timezone, I would expect the result to be the same as adding 86400 seconds to the original, unless there's something seriously bizarre going on with the size of the second. But if you convert, add 1 day, and convert back, you will get a different result if the two differ on DST. Does that sound plausible? 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
I agree and my 2 cents: I can expect something different depending on the timezone and DST if I add years months weeks days hours minutes seconds to a given datetime Even though, in 90% of the cases, there is a more or less obvious conversion formula between all of them. But consider months to days. That is not clear at all. On 27.07.2015 19:11, Chris Angelico wrote: On Tue, Jul 28, 2015 at 12:57 AM, Ronald Oussoren ronaldousso...@mac.com wrote: IMHO “+ 1 days” and “+ 24 hours” are two different things. Date arithmetic is full of messy things like that. “+ 1 month” is another example of that (which the datetime module punts completely and can be a source of endless bikeshidding). https://www.youtube.com/watch?v=ppfpa5XgZHI MATLAB defines + 1 month as, if I'm not mistaken, add the time it would take to go from the beginning of time to the beginning of January of the year 0 (which is totally a thing, by the way). I'm fairly sure that this is the most WAT-worthy definition possible, as it means that adding one month does nothing, and adding two months adds the length of January (31 days)... and adding three months adds January + February, *in a leap year*. But I agree that adding days and adding hours are different things. If I add one day, I expect that the time portion should not change, in the given timezone. (With the exception that DST switches might mean that that time doesn't exist.) If I add 86400 seconds, I expect that it should add 86400 ISO seconds to the time period, which might not be the same thing. If you convert a datetime to a different timezone, add 86400 seconds, and convert back to the original timezone, I would expect the result to be the same as adding 86400 seconds to the original, unless there's something seriously bizarre going on with the size of the second. But if you convert, add 1 day, and convert back, you will get a different result if the two differ on DST. Does that sound plausible? 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/srkunze%40mail.de ___ 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 6:42 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: I think this describes what was originally your *second*, not *first* option. Yes, you are absolutely correct, I didn't read my own description of the options carefully enough. ___ 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 27 Jul 2015, at 04:04, Tim Peters tim.pet...@gmail.com wrote: As an example, consider an alarm clock. I want it to go off at 7am each morning. I'd feel completely justified in writing tomorrows_alarm = todays_alarm + timedelta(days=1). If the time changes to DST overnight, I still want the alarm to go off at 7am. Even though +1 day is in this case actually + 25 (or is it 23?) hours. That's the current semantics. There was a long list of use cases coming to the same conclusion. The current arithmetic allows uniform patterns in local time to be coded in uniform, straightforward ways. Indeed, in the obvious ways. The alternative behavior favors uniform patterns in UTC, but who cares? ;-) Few local clocks show UTC. Trying to code uniform local-time behaviors using aware arithmetic (which is uniform in UTC. but may be lumpy in local time) can be a nightmare. The canonical counterexample is a nuclear reactor that needs to be vented every 24 hours. To which the canonical rejoinder is that the programmer in charge of that system is criminally incompetent if they're using _any_ notion of time other than UTC ;-) IMHO “+ 1 days” and “+ 24 hours” are two different things. Date arithmetic is full of messy things like that. “+ 1 month” is another example of that (which the datetime module punts completely and can be a source of endless bikeshidding). 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] Status on PEP-431 Timezones
On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro rege...@gmail.com wrote: On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath nikol...@rath.org wrote: On Jul 27 2015, Lennart Regebro rege...@gmail.com wrote: (The *first* option) That you add one hour to it, and the datetime moves forward one hour in actual time? That's doable, but during certain circumstance this may mean that you go from 1AM to 1AM, or from 1AM to 3AM. (The *second* option) Or do you expect that adding one hour will increase the hour count with one, ie that the wall time increases with one hour? ... Can you tell us which of the two operations datetime currently implements? It's intended that the first one is implemented, meaning that datetime.now() + timedelta(hours=24) can result in a datetime somewhere between 23 and 25 hours into the future. I think this describes what was originally your *second*, not *first* option. It will also help if you focus on one use case at a time. Your original example dealt with adding 1 hour, but now you switch to adding 24. In my previous email, I explained what is currently doable using the datetime module: t = datetime(2014,11,2,5,tzinfo=timezone.utc).astimezone() t.strftime(%D %T%z %Z) '11/02/14 01:00:00-0400 EDT' (t+timedelta(hours=1)).astimezone().strftime(%D %T%z %Z) '11/02/14 01:00:00-0500 EST' Is this your *first* or your *second* option? Note that this is not what is intended. This is an actual Python 3.4.3 session. ___ 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 27 July 2015 at 17:30, Lennart Regebro rege...@gmail.com wrote: Apologies for asking yet another dumb question about this, but I have the impression that a lot of other people are struggling with the basics here too. Can you tell us which of the two operations datetime currently implements? It's intended that the first one is implemented, meaning that datetime.now() + timedelta(hours=24) can result in a datetime somewhere between 23 and 25 hours into the future. Or well, any amount, in theory, I guess some changes are more than an hour, but that's very unusual. Maybe that's what the PEP intends. But the stdlib as currently implemented simply adds the appropriate number to the relevant field (i.e., increase the hour count with one). It's not possible to detect the difference between these two using only stdlib timezones, though, as those are all fixed-offset. Both Tim and I have pointed out that Guido's original intention was precisely what is implemented, for better or worse. What Guido's view was on DST-aware timezones and whether the behaviour was appropriate for those, I don't know personally (maybe Tim does). It may well be that it was let's not think about it for now. If we can ever straighten out what the question is, maybe Guido can chip in and answer it :-) Paul PS Ideally, Guido could pop into his time machine and fix the whole issue at source. But apparently he can't, because the time machine isn't DST-aware... ___ 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 ronaldousso...@mac.com] IMHO “+ 1 days” and “+ 24 hours” are two different things. Date arithmetic is full of messy things like that. But it's a fact that they _are_ the same in naive time, which Python's datetime single-timezone arithmetic implements: - A minute is exactly 60 seconds. - An hour is exactly 60 minutes. - A day is exactly 24 hours. - A week is exactly 7 days. No context is necessary: those are always true in naive time, and that lack of mess is a feature to those who accept it for what it is. “+ 1 month” is another example of that (which the datetime module punts completely and can be a source of endless bikeshidding). Note that the only units timedelta accepts have clear (utterly inarguable) meanings in naive time. That's intentional too. For example, a month and a year have no clear meanings (as durations) in naive time, so timedelta doesn't even pretend to support them. Despite all appearance to the contrary in this thread, naive time is bikeshed-free: it's easy for someone to know all there is to know about it by the time they're 12 ;-) datetime + timedelta(days=1) is equivalent to datetime + timedelta(hours=24) is equivalent to datetime + timedelta(minutes=60*24) is equivalent to datetime + timedelta(seconds=60*60*24) is equivalent to datetime + timedelta(microseconds=100*60*60*24) Naive time is easy to understand, reason about, and work with. When it comes to the real world, political adjustments to and within time zones can make the results dodgy, typically in the two DST-transition hours per year when most people living in a given time zone are sleeping. How much complexity do you want to endure in case they wake up? ;-) Guido's answer was none in arithmetic - push all the complexity into conversions - then most uses can blissfully ignore the complexities. And note that because DST transitions cancel out over the span of a year, the benefits and the few dodgy cases don't really change regardless of whether you add one week or a hundred thousand weeks (although there's no way to predict what governments will decide the local clock should say a hundred thousand weeks from now - it's only predictable in naive time). ___ 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
The days attribute here is indeed confusing as it doesn't mean 1 day, it means 24 hours. Which, in naive arithmetic, are exactly the same thing. [Terry Reedy] I think using the word 'naive' is both inaccurate and a mistake. The issue is civil or legal time versus STEM time, where the latter includes applications like baking cakes. Sorry, never heard of STEM time before - a quick Google search didn't help. It could also be called calendar time versus elapsed time. (Financial/legal arithmetic versus STEM arithmetic is a somewhat similar contrast.) And I am, alas, equally unclear on what any of those others mean (exactly) to you. The idea that an hour can be sliced out of a somewhat random March day and inserting it into a somewhat random October day is rather sophisticated. It came from the minds of government bureaucrats. It might be smart, dumb, or just a cunning way for civil authorities to show who is in charge by making us all jump. But not 'naive'. I agree. Python's naive time single-timezone arithmetic intentionally ignores all that: it ignores leap seconds, it ignores DST transition points, it ignores governments deciding to change the base UTC offset within a pre-existing time zone, ... It's time s naive that it thinks 24 hours is the same thing as a day ;-) 'Naive' means simple, primitive, or deficient in informed judgement. It is easy to take it as connoting 'wrong'. While some people in this thread seem convinced Python's naive time _is_ wrong, it's not because it's called naive. In any case, Guido decided to call it naive over 13 years ago, starting here, and that terminology has been in use ever since: https://mail.python.org/pipermail/python-dev/2002-March/020648.html Tim, you have been arguing that civil/legal time arithmetic is not naive. Yes. But that's not an argument, it's a plain fact that Python's naive time (note that naive here is technical term, used widely in the datetime docs) is not civil/legal time (assuming I understand what you mean by that phrase). Calling civil time naive undercuts this claim. I don't see that I ever said civil time is naive. Adding a day is _not_ always the same as adding 24 hours in (at least Lennart's beliefs about) civil time. They _are_ always the same in Python's (naive) datetime arithmetic. And the latter is all I said in the quote at the top of this msg. What am I missing? It's always something ;-) ___ 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 7/27/2015 3:09 AM, Tim Peters wrote: [Paul Moore p.f.mo...@gmail.com] As an example, consider an alarm clock. I want it to go off at 7am each morning. I'd feel completely justified in writing tomorrows_alarm = todays_alarm + timedelta(days=1). [Lennart Regebro rege...@gmail.com] That's a calendar operation made with a timedelta. It's an instance of single-timezone datetime arithmetic, of the datetime + timedelta form. Your examples have been of the same form. Note that after Paul's tomorrows_alarm = todays_alarm + timedelta(days=1) it's guaranteed that assert tomorrows_alarm - todays_alarm == timedelta(days=1) will succeed too. The days attribute here is indeed confusing as it doesn't mean 1 day, it means 24 hours. Which, in naive arithmetic, are exactly the same thing. I think using the word 'naive' is both inaccurate and a mistake. The issue is civil or legal time versus STEM time, where the latter includes applications like baking cakes. It could also be called calendar time versus elapsed time. (Financial/legal arithmetic versus STEM arithmetic is a somewhat similar contrast.) The idea that an hour can be sliced out of a somewhat random March day and inserting it into a somewhat random October day is rather sophisticated. It came from the minds of government bureaucrats. It might be smart, dumb, or just a cunning way for civil authorities to show who is in charge by making us all jump. But not 'naive'. 'Naive' means simple, primitive, or deficient in informed judgement. It is easy to take it as connoting 'wrong'. Tim, you have been arguing that civil/legal time arithmetic is not naive. Calling civil time naive undercuts this claim. -- Terry Jan Reedy ___ 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
On 7/27/2015 10:25 AM, Mark Kelley wrote: Thanks, that got me a bit further. Now I'm wondering how I figure out which version of tcl,tk and Tix actually got built with the 2.7.10 installer. This is really a python-list question, but for the PSF installer, tcl/tk 8.5.15 -- Terry Jan Reedy ___ 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 7/27/2015 3:14 PM, Tim Peters wrote: [Terry Reedy] I think using the word 'naive' is both inaccurate and a mistake. The issue is civil or legal time versus STEM time, where the latter includes applications like baking cakes. Sorry, never heard of STEM time before - a quick Google search didn't help. Searching for 'STEM' to discover the meaning of the acronym displays, for me, after the second STEM is an acronym referring to the academic disciplines of science, technology, engineering and mathematics. STEM time is the time used in science, technology, engineering and mathematics, with the added note indicating that I mean for technology and engineering to be taken broadly, to include all uses of actual (natural) elapsed time, as opposed to occasionally artificial government time. The idea that an hour can be sliced out of a somewhat random March day and inserting it into a somewhat random October day is rather sophisticated. It came from the minds of government bureaucrats. It might be smart, dumb, or just a cunning way for civil authorities to show who is in charge by making us all jump. But not 'naive'. I agree. Python's naive time single-timezone arithmetic intentionally ignores all that: it ignores leap seconds, it ignores DST transition points, it ignores governments deciding to change the base UTC offset within a pre-existing time zone, ... It's time s naive that it thinks 24 hours is the same thing as a day ;-) To me, having 1 day be 23 or 25 hours of elapsed time on the DST transition days, as in Paul's alarm example, hardly ignores the transition point. -- Terry Jan Reedy ___ 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
[Chris Barker] ... and infact, everything Tim said can also apply to UTC time. We've had a lot of discussion on teh numpy list about the difference between UTC and naive times, but for practicle putrposes, they are exactly the same -- unitl you try to convert to a known time zone anyway. Yes, naive arithmetic is correct (by everyone's definition) in any time zone that has a fixed-for-all-eternity offset from UTC. UTC is the simplest case of that (with offset 0). So for all practical purposes you can think of a naive datetime as being the time in any eternally-fixed-offset time zone you like - or as in no time zone at all (the time zone _concept_ isn't necessary to grasp naive time - it only takes effort to _forget_ it). But the paranoid should consider that nothing can stop governments from changing the definition of UTC (or any other time zone). They'll have to pry your naive datetimes out of your computer's cold, dead disk drives though ;-) ... 2) Calendar time arithmetic: this is things like next year, next week, two years from now -- these are quite tricky, and in some special cases have no obvious clear definition (leap years, etc...). Calendar manipulations like (2) should be kept completely separate from time span manipulation. Is anyone suggesting adding that to the standard lib? It comes up, and would be useful to many. But it's the kind of thing waiting for an extension module to take the world by storm. If people think the bikeshedding in _this_ thread is excessive ... ;-) ___ 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 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. -- Terry Jan Reedy ___ 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] But it's a fact that they _are_ the same in naive time, which Python's datetime single-timezone arithmetic implements: - A minute is exactly 60 seconds. ... [Chris Angelico ros...@gmail.com] No leap second support, presumably. Also feature? Absolutely none, and absolutely a feature, but that didn't start with the datetime module. Read Guido's original 13+ year old message about naive time: https://mail.python.org/pipermail/python-dev/2002-March/020648.html Note especially this part: I'm thinking that for most *business* uses of date and time, we should have the same attitude towards DST that we've already decided to take towards leap seconds. Guido has never had the slightest use for leap seconds in any part of Python's implementation, and has consistently opposed attempts to incorporate them. This was well established long before datetime was even an idea. Here's another, later quote from him: Python's datetime objects will not support leap seconds in any way, shape or form. A tzinfo object that does support leap seconds is on its own, but I don't see the point since Python will never represent a time as a number of seconds since some epoch. (If you want to get a POSIX time_t value, you'll have to convert first to local time, then to a struct tm, and then use mktime().) ___ 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 4:49 AM, Tim Peters tim.pet...@gmail.com wrote: But it's a fact that they _are_ the same in naive time, which Python's datetime single-timezone arithmetic implements: - A minute is exactly 60 seconds. No leap second support, presumably. Also feature? 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 Mon, Jul 27, 2015 at 11:55 AM, Terry Reedy tjre...@udel.edu wrote: I think using the word 'naive' is both inaccurate and a mistake. snip 'Naive' means simple, primitive, or deficient in informed judgement. It is easy to take it as connoting 'wrong'. In this context naive means having no knowledge of timezone. And it does make some sense as a word to use in that case. I don't like it much, but it's the term used in the datetime module docs, so there you go. and infact, everything Tim said can also apply to UTC time. We've had a lot of discussion on teh numpy list about the difference between UTC and naive times, but for practicle putrposes, they are exactly the same -- unitl you try to convert to a known time zone anyway. But really, the points Tim was making are not about timezones at all -- but about two concepts: Time arithmetic with: 1) Time spans (timedeltas) -- this is an amount of time, and can be added, subtracted, etc to a datetime. such time spans have various appropriate units, like seconds, days. weeks -- but, as Tim pointed out, years is NOT an appropriate unit of timedeltas, and should not be allowed in any lib that uses them. 2) Calendar time arithmetic: this is things like next year, next week, two years from now -- these are quite tricky, and in some special cases have no obvious clear definition (leap years, etc...). Calendar manipulations like (2) should be kept completely separate from time span manipulation. Is anyone suggesting adding that to the standard lib? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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 tjre...@udel.edu] To me, having 1 day be 23 or 25 hours of elapsed time on the DST transition days, as in Paul's alarm example, hardly ignores the transition point. It's 2:56PM. What time will it be 24 hours from now? If your answer is not enough information to say, but it will be some minute between 1.56PM and 3:56PM inclusive, you want to call _that_ naive? I sure don't. You can only give such an answer if you're acutely aware of (for example) DST transitions. If you're truly naive, utterly unaware of the possibility of occasional time zone adjustments, then you give the obvious answer: 2:56PM. That's what Python's datetime arithmetic gives. That's naive in both technical and colloquial senses. You're only aware of that 2:56PM tomorrow may be anywhere between 23 and 25 hours away from 2:56PM today because you're _not_ ignoring possible transitions. So,. sure, I agree that your pointing it out hardly ignores the transition point. But I wasn't talking about you ;-) I was talking about the arithmetic, which does thoroughly ignore it. ___ 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 12:07 PM, Chris Angelico ros...@gmail.com wrote: - A minute is exactly 60 seconds. No leap second support, presumably. Also feature? Leap seconds come in when you convert to a Calendar representation -- a minute is 60 seconds, always -- even when passing over a leap second. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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 07/27/2015 07:46 AM, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano wrote: To me, Paul's example is a datetime operation: you start with a datetime (7am today), perform arithmetic on it by adding a period of time (one day), and get a datetime as the result (7am tomorrow). Well, OK, let's propose these wordings: It looks like a date operation, ie, add one to the date, but in reality it's a time operation, ie add 86400 seconds to the time. These things sound similar but are very different. I have to disagree. If I have my alarm at 7am (localtime ;) so I can be at work at 8am I don't care exactly how many seconds have passed, that alarm better go off at 7am local time. -- ~Ethan~ ___ 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
[Paul Moore] ... I think the following statements are true. If they aren't, I'd appreciate clarification. I'm going to completely ignore leap seconds in the following - I hope that's OK, I don't understand leap seconds *at all* and I don't work in any application areas where they are relevant (to my knowledge) so I feel that for my situation, ignoring them (and being able to) is reasonable. Guido will never allow any aspect of leap seconds into the core, although it's fine by him if someone wants to write their own tzinfo class to try to model them. Note that I'm not talking about internal representations - this is purely about user-visible semantics. 1. Naive datetime arithmetic means treating a day as 24 hours, an hour as 60 minutes, etc. Basically base-24/60/60 arithmetic. It also means that the tzinfo(s) member (if any) is(are) ignored. So not only leap seconds are ignored: 1. Possible DST transitions are ignored. 2. Possible changes to the base UTC offset are ignored. 3. Possible changes to the name of the time zone (even if the rules don't change) are ignored. 4. Everything else whatsover that could be learned from the tzinfo member is ignored. Note that in aware arithmetic, the current fromutc() implementation is only strong enough to account reliably for #1. 2. If you're only working in a single timezone that's defined as UTC or a fixed offset from UTC, naive arithmetic is basically all there is. Yup! 3. Converting between (fixed offset) timezones is a separate issue from calculation - but it's nothing more than applying the relevant offsets. Yup! Although that can't be exploited by Python: there's nothing in a tzinfo instance Python can query to discover the rules it implements. 4. Calculations involving 2 different timezones (fixed-offset ones as above) is like any other exercise involving values on different scales. Convert both values to a common scale (in this case, a common timezone) and do the calculation there. Simple enough. Yup. 5. The problems all arise *only* with timezones whose UTC offset varies depending on the actual time (e.g., timezones that include the transition to DST and back). Yup. Are we OK to this point? This much comprises what I would class as a naive (i.e. 99% of the population ;-)) understanding of datetimes. The stdlib datetime module handles naive datetime values, and fixed-offset timezones, fine, as far as I can see. It ignores the possibility called #3 above (that some bureaucrat changed the name of a fixed-offset time zone despite that the offset didn't change). Everyone ignores #4, and always will ;-) (I'm not sure that the original implementation included fixed-offset tzinfo objects, but the 3.4 docs say they are there now, so that's fine). The original implementation supplied no tzinfo objects, only an abstract tzinfo base class. Looking at the complicated cases, the only ones I'm actually aware of in practice are the ones that switch to DST and back, so typically have two offsets that differ by an hour, Some number of minutes, anyway (not all DST transitions move by whole hours). switching between the two at some essentially arbitrary points. If there are other more complex forms of timezone, I'd like to never need to know about them, please ;-) #2 above is common enough, although there's not a _lot_ of base-offset-changing going on in current times. The timezones we're talking about here are things like Europe/London, not GMT or BST (the latter two are fixed-offset). There are two independent issues with complex timezones: 1. Converting to and from them. That's messy because the conversion to UTC needs more information than just the date time (typically, for example, there is a day when 01:45:00 maps to 2 distinct UTC times). This is basically the is_dst bit that Tim discussed in an earlier post. The semantic issue here is that users typically say 01:45 and it never occurs to them to even think about *which* 01:45 they mean. So recovering that extra information is hard (it's like dealing with byte streams where the user didn't provide details of the text encoding used). Flatly impossible is more on target than hard. In the case of text encoding, it's often possible to guess correctly by statistical analysis of the bytes. 01:45:00 in isolation gives no clue at all about whether standard or daylight time was intended. A similar point applies to some ambiguous cases when the base (standard) UTC offset changes. Once we have the extra information, though, doing conversions is just a matter of applying a set of rules. Yup, and it's easy. 2. Arithmetic within a complex timezone. Theoretically, this is simple enough (convert to UTC, do the calculation naively, and convert back). But in practice, that approach doesn't always match user expectations. So you have 2 mutually incompatible semantic options - 1 day after 4pm is 3pm the following day, or adding 1 day adds 25 hours -
Re: [Python-Dev] Status on PEP-431 Timezones
On Mon, Jul 27, 2015 at 7:49 AM Lennart Regebro rege...@gmail.com wrote: On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan ncogh...@gmail.com wrote: On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com wrote: Am I the only one feeling like this entire thread should be moved to python-ideas at this point? Since this is an area where the discussion of implementation details and the discussion of the developer experience can easily end up at cross purposes, I'm wondering if there may be value in actually splitting those two discussions into different venues by creating a datetime-sig, and specifically inviting the pytz and dateutil developers to participate in the SIG as well. +1 for that. Alexander and Tim, you okay with moving this conversation to a datetime-sig if we got one created? ___ 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] Python didn't implement timezone-aware arithmetic at all within a single time zone. Read what I wrote just above. It implements naive arithmetic within a single time zone. [Jon Ribbens jon+python-...@unequivocal.co.uk] This usage of time zone is confusing. Ha! _All_ usages of time zone are confusing ;-) This specific use pointed at something pretty trivial to state but technical: any instance of Python datetime arithmetic in which the datetime input(s) and, possibly also the output, share the same tzinfo member(s). Specifically: datetime + timedelta datetime - timedelta datetime - datetime Maybe another, but you get the idea. Those all do naive datetime arithmetic, and in the last case the same tzinfo member part is crucial (if the input datetimes have different tzinfo members in subtraction, we're no longer within a single time zone, and time zone adjustments _are_ made: it acts like both inputs are converted to UTC before subtracting; but not so if both inputs share their tzinfo members). As far as I can tell, you really mean UTC offset. A time zone would be something like Europe/London, which has two different UTC offsets throughout the year (not to mention other historical weirdnesses), whereas arithmetic on a timezone-aware datetime : is only going to work so long as you don't cross any of the boundaries where the UTC offset changes. In this context I only had in mind tzinfo members. They may represent fixed-offset or multiple-offset time zones (or anything else a programmer dreams up), or may even be None. The datetime implementation has no idea what they represent: the implementation can only judge whether two given tzinfo objects are or aren't the same object. So within a single time zone here just means there's only one tzinfo object in play. I agree with you about pretty much everything else about datetime, just I find the terminology misleading. 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 - but it's too late to do anything about that now, of course. At the time, Guido ran his time machine forward, and saw that Stuart Bishop would soon enough supply all the time zones known to mankind ;-) ___ 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
[Brett Cannon br...@python.org] \ Alexander and Tim, you okay with moving this conversation to a datetime-sig if we got one created? Fine by me! ___ 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 07/27/2015 01:42 PM, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman wrote: On 07/27/2015 07:46 AM, Lennart Regebro wrote: Well, OK, let's propose these wordings: It looks like a date operation, ie, add one to the date, but in reality it's a time operation, ie add 86400 seconds to the time. These things sound similar but are very different. I have to disagree. If I have my alarm at 7am (localtime ;) so I can be at work at 8am I don't care exactly how many seconds have passed, that alarm better go off at 7am local time. Right. And then adding 86400 seconds to it is not the right thing to do. Yes, it is, because that's the number that will get me to 7am the next day. My program has no control over the computer's clock -- it merely works with what it is told by the computer's clock. -- ~Ethan~ ___ 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 27 July 2015 at 22:10, Tim Peters tim.pet...@gmail.com wrote: 1. Converting to and from them. That's messy because the conversion to UTC needs more information than just the date time (typically, for example, there is a day when 01:45:00 maps to 2 distinct UTC times). This is basically the is_dst bit that Tim discussed in an earlier post. The semantic issue here is that users typically say 01:45 and it never occurs to them to even think about *which* 01:45 they mean. So recovering that extra information is hard (it's like dealing with byte streams where the user didn't provide details of the text encoding used). Flatly impossible is more on target than hard. In the case of text encoding, it's often possible to guess correctly by statistical analysis of the bytes. 01:45:00 in isolation gives no clue at all about whether standard or daylight time was intended. A similar point applies to some ambiguous cases when the base (standard) UTC offset changes. By hard, what I meant was that you'd have to explain what you need to the user, and accept their answer, in the user interface to your application. Explaining why you need to know in a way that isn't totally confusing is what I classed as hard. I wouldn't even consider trying to guess the user's intent. Although if you don't say, I'll use naive datetimes seems to me a plausible position to take if you want to allow the user not to care. Strange that this is how Python works... ;-) 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 02:04 AM, Tim Peters wrote: The naive arithmetic within a timezone is already correct, by its own internal criteria. It's also useful (see the original discussions, or Paul Moore's recent brief account). Naive alarm clocks (those which don't know from timezones) break human expectations twice a year, because their users have to be awake to fix them (or make the clock itself out-of-whack with real civil time for the hours between fixing and the actual transition). For confirmatoin, ask your local priest / pastor about the twice yearly mixups among congregants whose clocks don't self-adjust for the DST boundary: some show up late / early for church *every* time the local zone changes. I'd be in favor of dropping days from timedelta, myself, for just this reason: if 1 day is the same for your usecase as 24 hours, then just do the math yourself. 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) iQIcBAEBAgAGBQJVtqPcAAoJEPKpaDSJE9HY4oEP+wUSWTeQS7cn3FLVBOeUV/lZ MIqZSnIGYOaSS6JDo2oTjm+yQWySEp5QMXHNYohPOkkkYDdu8L/r250KKb6F3fbo OMnNXlBCVHi66kFCs0x3+zQIlhSzkYV2FcT39gNu0llw5gODtmbbvYZE+CA4ej6R PIhnizyT7bXa+q2WYBrL0/+w/IBuv4H3d/x0b79cPZpqRZeI57k90qsee9SSPyDb MGs76IUOfJuZNruqfuY+zhFlfwB5kOt8U4kTlXZS4At1TKskoH5zuIiaHZooN6gy fBz3Zzt2XKYiWPWrzEbVeXrdXmAFRyr5sWqVQ0SliKA06rq1Tr5h53orGLidMaPe noUnz8YQHssY5e/kAbSUv6C93GNbldNEFOV1Ab03JT+NPrhNxPqi1ZGTJsMDc+Tl HI2I5C1TXW8ZPx/US2+Zt0yu0HX82EX03UPlRW4wZZSyKw7eCosF9fWXwufF9yTP 9v0otEB/x3rN1TJgc+7U4r1JmYPy+eYyjKs1xy58kb/a7awSvlmEeWvQelGqQKc+ lnRT6VxzVlgmTginq/5oHyFkI5OFTYuukuQDZx3ocd1g7EX42pNRYHVcMbZiQ9L5 DFKrENQDkegTkX+g1BUlVSW67smrFfki6Y7O/5R378x+q/sn6oqYe9334C+ccbz8 8jA16niF9EiwaxieLH9w =I31e -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 Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman et...@stoneleaf.us wrote: On 07/27/2015 07:46 AM, Lennart Regebro wrote: Well, OK, let's propose these wordings: It looks like a date operation, ie, add one to the date, but in reality it's a time operation, ie add 86400 seconds to the time. These things sound similar but are very different. I have to disagree. If I have my alarm at 7am (localtime ;) so I can be at work at 8am I don't care exactly how many seconds have passed, that alarm better go off at 7am local time. Right. And then adding 86400 seconds to it is not the right thing to do. //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
To use Alexander's example:
-- t = datetime(2015, 3, 7, 12, tzinfo=timezone('US/Eastern'))
-- t.strftime('%D %T %z %Z')
'03/07/15 12:00:00 -0500 EST'
-- (t + timedelta(1)).strftime('%D %T %z %Z')
'03/08/15 12:00:00 -0400 EDT'
The data (aka the time) should act naively, but the metadata (aka the timezone)
is what should be changing [1].
--
~Ethan~
[1] Which is to say that naive datetime's should continue as-is, and aware
datetimes should exhibit the above behavior.
___
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 7/27/2015 1:42 PM, Lennart Regebro wrote: On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman et...@stoneleaf.us wrote: On 07/27/2015 07:46 AM, Lennart Regebro wrote: Well, OK, let's propose these wordings: It looks like a date operation, ie, add one to the date, but in reality it's a time operation, ie add 86400 seconds to the time. These things sound similar but are very different. I have to disagree. If I have my alarm at 7am (localtime ;) so I can be at work at 8am I don't care exactly how many seconds have passed, that alarm better go off at 7am local time. Right. And then adding 86400 seconds to it is not the right thing to do. It is the right thing to do... but one also adds/subtracts 3600 seconds from it before going to bed 2 days a year, due to government interference, unless it is an atomic clock or cell-phone, which do those updates automatically. ___ 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] Please create the datetime-sig mailing list
[bcc'ed python-dev] Initial admin can be me and I will be in charge of finding more suitable admins to manage the list. ___ 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 27 jul. 2015, at 20:49, Tim Peters tim.pet...@gmail.com wrote: [Ronald Oussoren ronaldousso...@mac.com] IMHO “+ 1 days” and “+ 24 hours” are two different things. Date arithmetic is full of messy things like that. But it's a fact that they _are_ the same in naive time, which Python's datetime single-timezone arithmetic implements: ... Naive time is easy to understand, reason about, and work with. When it comes to the real world, political adjustments to and within time zones can make the results dodgy, typically in the two DST-transition hours per year when most people living in a given time zone are sleeping. How much complexity do you want to endure in case they wake up? ;-) Guido's answer was none in arithmetic - push all the complexity into conversions - then most uses can blissfully ignore the complexities. 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. 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. That said, I have had the need for date delta objects that can deal with deltas expressed at days or months but it is easy enough to write your own library for that that can deal with the local conventions for those. 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] Status on PEP-431 Timezones
On Mon, Jul 27, 2015 at 5:13 PM, Tim Peters tim.pet...@gmail.com wrote: [Brett Cannon br...@python.org] \ Alexander and Tim, you okay with moving this conversation to a datetime-sig if we got one created? Fine by me! +1 Didn't datetime-sig exist some 12 years ago? It would be nice to get some continuity from that effort. ___ 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 12:47 PM, Ethan Furman et...@stoneleaf.us wrote: To me, Paul's example is a datetime operation: you start with a datetime (7am today), perform arithmetic on it by adding a period of time (one day), and get a datetime as the result (7am tomorrow). Well, OK, let's propose these wordings: It looks like a date operation, ie, add one to the date, but in reality it's a time operation, ie add 86400 seconds to the time. These things sound similar but are very different. I have to disagree. If I have my alarm at 7am (localtime ;) so I can be at work at 8am I don't care exactly how many seconds have passed, that alarm better go off at 7am local time. sure, but that is very much a Calendar operation -- 7am tomorrow, On the other hand, if you wanted to sleep a particular length of time,t hen you might want your alarm to go off in 8 hours -- that is a different operation. Calendar operations are very, very useful, but not on the table in this discussion, are they? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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
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! (Also, technically, UTC would use leap-seconds...) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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 tsea...@palladion.com] Naive alarm clocks (those which don't know from timezones) break human expectations twice a year, because their users have to be awake to fix them (or make the clock itself out-of-whack with real civil time for the hours between fixing and the actual transition). For confirmatoin, ask your local priest / pastor about the twice yearly mixups among congregants whose clocks don't self-adjust for the DST boundary: some show up late / early for church *every* time the local zone changes. Sure. I don't see how this applies to Python's arithmetic, though. For a start, you're talking about alarm clocks ;-) Note that naive is a technical term in the datetime context, used all over the datetime docs. However, I'm using naive arithmetic as a shorthand for what would otherwise be a wall of text. That's my own usage; the docs only apply naive and aware to date, time and datetime objects (not to operations on such objects). I'd be in favor of dropping days from timedelta, myself, for just this reason: if 1 day is the same for your usecase as 24 hours, then just do the math yourself. timedelta objects only store days, seconds, and microseconds, which is advertised. It would be bizarre not to allow to set them directly. They're the only timedelta components for which instance attributes exist. In the timedelta constructor, it's the seconds, milliseconds, minutes, hours, and weeks arguments that exist solely for convenience. You could do the math yourself for all those too - but why would you want to make anyone do that for any of them? All the world's alarm clocks would remain just as broken regardless ;-) Even if days weren't a distinguished unit for timedelta, I'd still much rather write, e.g., timedelta(days=5, hours=3) than timedelta(hours=123) or timedelta(hours=5*24 + 3) etc. The intent of the first spelling is obvious at a glance. ___ 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
Responses to several partial messages follow. [Lennart Regebro] Then we can't implement timezones in a reasonable way with the current API, but have to have something like pytz's normalize() function or similar. I'm sorry I've wasted everyones time with this PEP. [ijs] I think that integrating pytz into the stdlib, which is what the PEP proposes, would be valuable even without changing datetime arithmetic. But I see ways to accomplish the latter without breaking backward compatibility. The dream ain't dead! See below. [Paul Moore] 2. Arithmetic within a complex timezone. Theoretically, this is simple enough (convert to UTC, do the calculation naively, and convert back). But in practice, that approach doesn't always match user expectations. So you have 2 mutually incompatible semantic options - 1 day after 4pm is 3pm the following day, or adding 1 day adds 25 hours - either is a viable choice, and either will confuse *some* set of users. This, I think, is the one where all the debate is occurring, and the one that makes my head explode. It seems to me that the problem is that for this latter issue, it's the *timedelta* object that's not rich enough. [ijs] Yes! This is the heart of the matter. We can solve *almost* all the problems by having multiple competing timedelta classes-- which we already have. Do you care about what will happen after a fixed amount of elapsed time? Use `numpy.timedelta64` or `pandas.Timedelta`. Want this time tomorrow, come hell, high water, or DST transition? Use `dateutil.relativedelta.relativedelta` or `mx.DateTime.RelativeDateTime`. As long as the timedelta objects we're using are rich enough, we can make `dt + delta` say what we mean. There's no reason we can't have both naive and aware arithmetic in the stdlib at once. All the stdlib needs is an added timedelta class that represents elapsed atomic clock time, and voila! The biggest problem that this can't solve is subtraction. Which timedelta type do you get by subtracting two datetimes? Sure, you can have a `datetime.elapsed_since(self, other: datetime, **kwargs) - some_timedelta_type` that determines what you want from the kwargs, but `datetime.__sub__` doesn't have that luxury. I think the right answer is that subtraction should yield the elapsed atomic clock time, but that would be a backward-incompatible change so I don't put a high probability on it happening any time soon. See the last message (below) for more on this. You can't say add 1 day, and by 1 day I mean keep the same time tomorrow as opposed to add 1 day, and by that I mean 24 hours[1]. In some ways, it's actually no different from the issue of adding 1 month to a date (which is equally ill-defined, but people know what they mean to just as great an extent). Python bypasses the latter by not having a timedelta for a month. C (and the time module) bypasses the former by limiting all time offsets to numbers of seconds - datetime gave us a richer timedelta object and hence has extra problems. Because of the limits on the values of its members, `datetime.timedelta` is effectively just a counter of microseconds. It can't distinguish between 1 day, 24 hours, 1440 minutes or 86400 seconds. They're all normalized to the same value. So it's not actually richer; it only appears so. I don't have any solutions to this final issue. But hopefully the above analysis (assuming it's accurate!) helps clarify what the actual debate is about, for those bystanders like me who are interested in following the discussion. With luck, maybe it also gives the experts an alternative perspective from which to think about the problem - who knows? Paul [1] Well, you can, actually - you say that a timedelta of 1 day means the same time tomorrow and if you want 24 hours, you say 24 hours not 1 day. So timedelta(days=1) != timedelta(hours=24) even though they give the same result for every case except arithmetic involving complex timezones. Is that what Lennart has been trying to say in his posts? I thought for a long time that this would be sufficient, and I still think it's a good spelling that makes it clear what the user wants most of the time, but I have wanted things like the first time the clock shows 1 hour later than it shows right now enough times that I no longer think this is quite sufficient. (I *think* you can do that with `dt + dateutil.relativedelta.relativedelta(hour=dt.hour+1, minute=0, second=0, microsecond=0)`, but I'm not sure.) [Tim Peters] Ah, but it already happens that way - because the builtin datetime arithmetic is naive. The docs have always promised this: datetime2 = datetime1 + timedelta (1) datetime2 = datetime1 - timedelta (2) 1) datetime2 is a duration of timedelta removed from datetime1, moving forward in time if timedelta.days 0, or backward if timedelta.days 0. The result has the same tzinfo attribute as the input datetime, and datetime2 - datetime1 == timedelta
Re: [Python-Dev] Status on PEP-431 Timezones
-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. 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) iQIcBAEBAgAGBQJVttcdAAoJEPKpaDSJE9HYSlEP/0b7A9swT3m0uImdmzSZNJCW EShQuxkclKlADP0Qqvshbiew1lsdqSPTZQ5QOUnqxeo+F0C1pCSABgFmXA3Jjzon lxbwOGFFDhBburJ/F5zAO3XnawvL2p/M4dV+3Zea2inO0X+iNUuHvNjwx/e/qR4i XdC8IyyJZtsFFL+l5KAv7xOT6SaCOB7OrVTZySHrhmfeziClzeBC8GWI00zYIQjj BYQJB+lLhSBdb3b4u2fqhGtbrFtTHDDHEPC/mWdWAvzJN98YaeOtiTOAqiIg5Xai TssJwAvonxOy5P8f5XdW03kbaKqmslWVk/0xIT7svjJnfPXVFzHoFJZZAJMEt34s uZXu79g5ype8gyIJceXZV9/iS6GKHhfUlNTRvemJZb1aiq1QJ26otv2n97yqFbdo PYfbjSU5EhK7h42138QYCM1JmKmIEIBbb+RN5O5ZaJqWEs1IstaMI1K7rM/Gt9dj +Du0wV85Vi0ydgrZ2w8z2ZCL3bnl5wW7y8mBiSNWx1OEK7zRn/tq7/+nd9bFi1L0 8KIY8xJn5t0SU+5BSpisxTSAdX8JD6bAPy3wZlNDP8FFfB9zUyCrhRE58cDsvPdO BQYteyWrpGQJxf2i5UQTLruW2JK3i1lL0en4spucQnBI/eHs7VVHMbfpOpdXhcIl TR7c9fNwV0kn7EggTajx =nRMI -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 01:58, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 06:03 PM, Tim Peters wrote: Even if days weren't a distinguished unit for timedelta, I'd still much rather write, e.g., timedelta(days=5, hours=3) than timedelta(hours=123) or timedelta(hours=5*24 + 3) etc. The intent of the first spelling is obvious at a glance. - 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. In a given application, a user who doesn't care can always write a helper function to generate hours; in an applicatino whose developer who *does* care, the 'days' argument to timedelta in its current does *not* help achieve her goal: it is an attractive nuisance she will have to learn to avoid. 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? -- 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
[Ronald Oussoren] 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. [Tres Seaver tsea...@palladion.com] 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). I strongly suspect that by naive objects here Ronald was really talking about naive _arithmetic_: the current behavior where adding 24 hours (or 1 day - exactly the same thing for a timedelta) to an aware datetime yields a new datetime with the same tzinfo member and the same local time components, but where the day (and possibly month, and possibly year) components have moved forward by a day (in the plain English meaning of a day). That behavior has been discussed approximately infinitely often so far in this thread, and was the overriding context in the message from which Ronald's quote was pulled. 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 bet the same is true for Ronald in some of his apps. 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? ;-) ___ 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
[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. The timedelta in question represents precisely 14 24-hours days, and ignores the possibility that some day in there may suffer a leap second. If you add that timedelta to a datetime object, the result may not be exactly 14*24 hours in the future as measured by civil time (which includes things like DST transitions). The result will have the same local time on the same day of the week two weeks forward. For example, if you started with Monday the 6th at 3:45pm, the result will be Monday the 20th at 3:45;pm. Period. The time zone (if any is attached) is wholly ignored throughout. If a DST transition occurs across that period, then it's impossible to say how far removed (as measured by. say, an independent stopwatch) Monday the 20th at 3:45pm is from Monday the 6th at 3:45pm without also knowing the month, the year, and the exact local time zone rules in effect across the period. 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). ___ 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 06:03 PM, Tim Peters wrote: Even if days weren't a distinguished unit for timedelta, I'd still much rather write, e.g., timedelta(days=5, hours=3) than timedelta(hours=123) or timedelta(hours=5*24 + 3) etc. The intent of the first spelling is obvious at a glance. - 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. In a given application, a user who doesn't care can always write a helper function to generate hours; in an applicatino whose developer who *does* care, the 'days' argument to timedelta in its current does *not* help achieve her goal: it is an attractive nuisance she will have to learn to avoid. 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) iQIcBAEBAgAGBQJVttPGAAoJEPKpaDSJE9HY0N4QAMQ+Q1/m6Dgg97aS1fRFrMA1 gi7lrWEuW0II0V9bOvB+j0IkASBahreauYb+MBnXXSy1JEDRpVQX7h4SHzLMQ+TF YSKnxCCY1UktpegkriZF7FoN8Rhv3egA01qWPO0RjHUkZym7/W2zN5cXhRTeij8N dbAcoT5y4gdii55T+edWjYNJDFihgKNEuh2KMPmMH37tYqOKCFsz1ojX2ox7e4dC 2yEACVz8G+bmUQQ/WXRKsM4pvMf616U9qkMcEYCVzqV+4smX+/z6c7gs244UVcr4 b4m6Du6UTNAtZpSkToYZvN9R2WbDmbG4FnUrF9eso7m1S2BjdlNyxJS7zGmp+Ttj XxmPeptC/INx8EaILYlB70gDDVztU+QBeolP9lfmfpY3srhI1a2uIGH2LhhOuy+F xcRoGaOIg3+JFyPa8ye6OAg6Vka9h+e02ZWaAAxfRhZgnnNduUnTaomuTKi8sCAa s3AHG4E5dOTJdLGxhgVEOSl9nqIJNmVxLxxb2utcS7W5G28KHYLzgV6w2r/fOkYf FvN5Lj6qQuQTPKdN807/7cl1fqOGPg4P74GMojVA816aNtjh4hTw/2AXqZ0Q0LTq QzhatRaDY+cu1SSZV9aDuCxvm4chjITucb6g7/dvR1xSY4Y+oxFgt3/KO2N5jJSY jBlJGbgGp9kukkwO2ret =Aw0Q -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 Mon, Jul 27, 2015 at 2:10 PM, Tim Peters tim.pet...@gmail.com wrote: Guido will never allow any aspect of leap seconds into the core, really? that is a shame (and odd) -- it's a trick, because we don't know what leap seconds will be needed in the future, but other than that, it's not really any different than leap years, and required for proper conversion to/from calendar description of time (at least for UTC, the GPS folks have their own ideas about all this). But leap seconds are the big red herring -- darn few people need them! It's pretty rare, indeed, to be expressing your time in gregorian dates, and also care about accuracy down to the seconds over centuries 2. If you're only working in a single timezone that's defined as UTC or a fixed offset from UTC, naive arithmetic is basically all there is. Yup! and remarkably useful! 5. The problems all arise *only* with timezones whose UTC offset varies depending on the actual time (e.g., timezones that include the transition to DST and back). Yup. which is a good reason to store your datetime in UTC, and do all the math there. Are we OK to this point? This much comprises what I would class as a naive (i.e. 99% of the population ;-)) understanding of datetimes. The stdlib datetime module handles naive datetime values, and fixed-offset timezones, fine, as far as I can see. It ignores the possibility called #3 above (that some bureaucrat changed the name of a fixed-offset time zone despite that the offset didn't change). Should the code ever care about a time zone's name? it seems that two tzinfo objects should only be considered the same if they ar the same instance. period. so not sure what the real issue is with (3) 2. Arithmetic within a complex timezone. Theoretically, this is simple enough (convert to UTC, do the calculation naively, and convert back). But in practice, that approach doesn't always match user expectations. what reasonable expectation does this not match? So you have 2 mutually incompatible semantic options - 1 day after 4pm is 3pm the following day, or adding 1 day adds 25 hours - either is a viable choice, and either will confuse *some* set of users. This, I think, is the one where all the debate is occurring, and the one that makes my head explode. This is what Ive been calling (is there a standard name for it?) a Calendar operation: this time the next day -- that could be 23, 24, or 25 hours, if you are bridging a DST transition -- but that kind of operation should not be in the stdlib -- unless, of course, an entire work with calendar time lib is added -- but that's a whole other story. for a datetime.timedelta -- a day is 24 hours is a day. period, always. So you can compute one day from now, which is the same as 24 hours from now or 1440 minutes from now, or , but you can't compute this time tomorrow -- not with a timedelta, anyway. Python picked one to make dead easy (naive), and intended to make the other _possible_ via longer-winded (but conceptually straightforward) code. exactly -- you can extract the year, month, day -- add one to the day, and then go back. But then you'll need to do all the 30 days hath September stuff - and leap years, and ... which is why all that is another ball of wax. And by the way -- doesn't dateutil have all that? datetime gave us a richer timedelta object and hence has extra problems. it's only a little richer, and doesn't really add problems, just doesn't solve some common problems... There's more to it than that. Naive time also wants, e.g., 01:45:00 tomorrow minus 01:45:00 today to return 24 hours. Maybe the same thing in disguise, though. I think so -- but it's not a problem because the datetime module doesn't have any way to express tomorrow anyway. [1] Well, you can, actually - you say that a timedelta of 1 day means the same time tomorrow and if you want 24 hours, you say 24 hours not 1 day. So timedelta(days=1) != timedelta(hours=24) even though they give the same result for every case except arithmetic involving complex timezones. they always give the same result -- even with complex time zones. I don't think timedelta evey needs to know about timezones at all. timedelta, is actually really, really simple, all it needs to know is how to translate various units into its internal representation (days, seconds, microseconds ?) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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 01:04:03AM -0500, Tim Peters wrote: [Tim] The Python docs also are quite clear about that all arithmetic within a single timezone is naive. That was intentional. The _intended_ way to do aware arithmetic was always to convert to UTC, do the arithmetic, then convert back. [Lennart] We can't explicitly implement incorrect timezone aware arithmetic and then expect people to not use it. Python didn't implement timezone-aware arithmetic at all within a single time zone. Read what I wrote just above. It implements naive arithmetic within a single time zone. This usage of time zone is confusing. As far as I can tell, you really mean UTC offset. A time zone would be something like Europe/London, which has two different UTC offsets throughout the year (not to mention other historical weirdnesses), whereas arithmetic on a timezone-aware datetime is only going to work so long as you don't cross any of the boundaries where the UTC offset changes. I agree with you about pretty much everything else about datetime, just I find the terminology misleading. 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 - but it's too late to do anything about that now, of course. ___ 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 12:03 AM, Tim Peters tim.pet...@gmail.com wrote: timedelta objects only store days, seconds, and microseconds, Except that they don't actually store days. They store 24 hour periods, which, because of timezones changing, is not the same thing. This is also clearly intended, for example timedelta allows floats, and will convert the fraction into seconds. And as you have repeated many times now, the datetime module's arithmetic is naive ie, it assumes that one day is always 24 hours. The problem with that assumption is that it isn't true. ___ 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 12:11 AM, Ronald Oussoren ronaldousso...@mac.com wrote: 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. If you don't have to deal with DST, then you don't have to have tzinfo's in your date objects. You can have just truly naive objects without DST information, and this will work just fine. I think most people's expectations are that datetime's that *are* time zone aware, should actually deal correctly with those time zones. 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. 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*. 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. ___ 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. 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 ___ 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 07/27/2015 10:08 PM, Lennart Regebro wrote: On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren wrote: 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. 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*. 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. Lennart, are you saying you would leave naive objects alone, and fix the tz-aware objects only? -- ~Ethan~ ___ 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
Paul Moore writes: On 27 July 2015 at 15:57, Ronald Oussoren ronaldousso...@mac.com wrote: IMHO “+ 1 days” and “+ 24 hours” are two different things. Date arithmetic is full of messy things like that. “+ 1 month” is another example of that (which the datetime module punts completely and can be a source of endless bikeshidding). Precisely. Er, to be exact, it's an accurate statement of imprecision (although when talking about time and computation, both accuracy and precision are ambiguous). Fortunately, there's a tim in time! ___ 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?
Robert Collins robe...@robertcollins.net writes: On 21 July 2015 at 00:34, Ben Finney ben+pyt...@benfinney.id.au wrote: Paul Moore p.f.mo...@gmail.com writes: Again, I'm sorry to pick on one sentence out of context, but it cut straight to my biggest fear when doing a commit (on any project) - what if, after all the worrying and consideration I put into doing this commit, people disagree with me (or worse still, I made a mistake)? Will I be able to justify what I decided? That seems quite healthy to me. On a collaborative project with effects far beyond oneself, yes, any change *should* be able to be justified when challenged. Depending on what you mean by justification , this leaves no leeway for hunches, feelings, intuition, or grey area changes. This doesn't address what I've said; or, I've misunderstood what you've said. I'm well aware that *most* of the changes we actually work on and introduce will be based on hunches, feelings, intuition, grey areas, etc. That can't be expected to disappear. 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. I'm not proposing to block every change based on those non-rational impulses. Those impulses reflect our internalised lessons that we've learned from experience. When someone's non-rational decisions prove reliably good *when challenged* by rational third-party interrogation, we correctly trust them to make more such decisions. That's not advocating subjecting a *person* to interrogation, with the connotations of moral judgement. Be clear: I'm talking only about interrogating the rational justification for a code change, separate from judgement of the person. So: we will inevitably make most of our decisions non-rationally, which means, among other things, *faster* than explicitly rational decision making. I don't propose to change that, and our trusted core developers are not expected to be any exception to this human truth. It has to be recognised, though, that there must be some third-party scrutiny, and if no *rational* justification can be presented for a change – whether tha justification is composed ahead of the change, or some time afterward, or even at the time of the challenge – then that change is rather likely to be a poor one. Again, this is *not* a call to subject every, or even most, changes to rigorous scrutiny. That would be an intolerably slow and oppressive environment, which I don't advocate. What I am rejectiong is the idea, expressed several times in this thread, that requesting rational justification for a change can be dismissed out of hand. That's abdicating any accountability, and I was quite concerned to see that attitute expressed. No one need feel accountable to me especially, or any other arbitrary member. Rather, I think it's healthy that core developers feel accountable to the principle that any change *should* be justifiable, when challenged by someone with sufficient authority; and that such an authoritative request is not answered by “it felt right to me”. It's also a terrible way to treat people that are contributing their own time and effort: assume good faith is a much better starting point. Agreed, we should assume good faith. Most decisions will be reached non-rationally, and we have no option but to trust some people to make many non-rational decisions. Simultaneously, when entrusted with such decisions, we must assume that any changes we make which can't be justified *when later challenged* should fall away. What we mustn't assume is that just because we have made good non-rational decisions in the past, the next one we make will also be well-justified. Especially, we should assume that anyone who *asks* for that rational justification is also acting in good faith. -- \ “The only tyrant I accept in this world is the still voice | `\ within.” —Mohandas K. Gandhi | _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
[Paul Moore] [Tim] Guido will never allow any aspect of leap seconds into the core, [Chris Barker chris.bar...@noaa.gov] really? that is a shame (and odd) -- it's a trick, because we don't know what leap seconds will be needed in the future, but other than that, it's not really any different than leap years, It couldn't be _more_ different in three key respects: 1) The leap year rules are algorithmic, while leap seconds are added at unpredictable times by decree. That means any attempt to support them across dozens of platforms also needs to find a way to distribute synchronize leap-second info across all the platforms too, over over over again. Few want to volunteer for yet another never-ending new task. 2) Leap years visibly effect everyone on the planet who uses a calendar. Leap seconds don't. To the contrary, civil authorities do all they can to keep leap seconds out of sight, out of mind. 3) If adding leap seconds had any visible semantic effect in Python, 99.99% of Python users would complain about being bothered with them. In contrast, removing leap-year support would cause 32.6% of Python users to complain - eventually ;-) ... But leap seconds are the big red herring -- darn few people need them! Do you? If not, put your energy instead into something you _do_ need ;-) But if you do need them, write a patch and try to sneak it by Guido. It's pretty rare, indeed, to be expressing your time in gregorian dates, and also care about accuracy down to the seconds over centuries Python's datetime supports microsecond precision. Mere seconds are for wimps ;-) ... 5. The problems all arise *only* with timezones whose UTC offset varies depending on the actual time (e.g., timezones that include the transition to DST and back). which is a good reason to store your datetime in UTC, and do all the math there. As mentioned earlier, uniform patterns in local time can be - typically because of DST transitions - lumpy in UTC. Like every Friday at 3pm in time zone T is trivial to deal with _in_ T using naive datetime arithmetic, but the corresponding datetimes in UTC are irregular (the number of hours between successive corresponding UTC times can slobber around between 167 and 169).. There are no one-size-fits-all solutions here. It ignores the possibility called #3 above (that some bureaucrat changed the name of a fixed-offset time zone despite that the offset didn't change). Should the code ever care about a time zone's name? it seems that two tzinfo objects should only be considered the same if they ar the same instance. period. so not sure what the real issue is with (3) _Users_ care. That's why the tzname() method exists. When they display it, it's at best confusing if the name they see doesn't match the name they expect. But I'm not sure _how_ the name can get out of synch. Upon reflection, the specific case I had in mind was actually caused by incorrect coding of a tzinfo subclass. Maybe that's the only way a wrong name can be returned (apart from incorrect names in the base zoneinfo data files). 2. Arithmetic within a complex timezone. Theoretically, this is simple enough (convert to UTC, do the calculation naively, and convert back). But in practice, that approach doesn't always match user expectations. what reasonable expectation does this not match? The every Friday at 3pm in time zone T example comes to mind: trying to do _that_ arithmetic in UTC is an irregular mess. More generally, as mentioned before, the current fromutc() implementation can't deal reliably with a time zone changing its standard UTC offset (if it isn't clear, fromutc() is used in astimezone(), which latter is used for time zone conversions). Paul, do you have something else in mind for this one? ... this time the next day -- that could be 23, 24, or 25 hours, if you are bridging a DST transition -- but that kind of operation should not be in the stdlib -- unless, of course, an entire work with calendar time lib is added -- but that's a whole other story. for a datetime.timedelta -- a day is 24 hours is a day. period, always. But in naive time, the difference between 3pm one day and 3pm the next day is also always 24 hours, period, always. So you can compute one day from now, which is the same as 24 hours from now or 1440 minutes from now, or , but you can't compute this time tomorrow -- not with a timedelta, anyway. To the contrary, for a dozen years + timedelta(days=1) HAS computed this time tomorrow, and exactly the same as + timedelta(hours=24). Those have never done anything other in Python. Python picked one to make dead easy (naive), and intended to make the other _possible_ via longer-winded (but conceptually straightforward) code. exactly -- you can extract the year, month, day -- add one to the day, and then go back. But then you'll need to do all the 30 days hath September stuff - and leap years, and ... It sounds like
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)
Stephen J. Turnbull step...@xemacs.org writes: […] The meta of special cases aren't special enough to break the rules is that no design decision that violates it should be dismissed as minor. Thank you. That dismissal was very upsetting; essentially telling Python users that their concerns for a clean API in the standard library aren't worth much to the Python core developers. In context of a mailing list, doing so is going to be taken by readers as I know what I'm doing, and you don't know what you're talking about, so STFU. That may not have been the intent. It certainly was how it was received by some of us here. *Both* roles in this comedy of errors are natural, they are inherent in human cognition (citations on request), and nobody is to be blamed. Since it can't seem to be said enough, I agree with what Stephen's saying here wholeheartedly: the above explications are not intended as blame, but an explanation of why calls to “stop talking about this, it's minor” had precisely the opposite effect. -- \ “Remember: every member of your ‘target audience’ also owns a | `\ broadcasting station. These ‘targets’ can shoot back.” —Michael | _o__) Rathbun to advertisers, news.admin.net-abuse.email | 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 Mon, Jul 27, 2015 at 12:15 AM, Paul Moore p.f.mo...@gmail.com wrote: I think the current naive semantics are useful and should not be discarded lightly. At an absolute minimum, there should be a clear, documented way to get the current semantics under any changed implementation. As an example, consider an alarm clock. I want it to go off at 7am each morning. I'd feel completely justified in writing tomorrows_alarm = todays_alarm + timedelta(days=1). That's a calendar operation made with a timedelta. The days attribute here is indeed confusing as it doesn't mean 1 day, it means 24 hours. //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
[Tim] The Python docs also are quite clear about that all arithmetic within a single timezone is naive. That was intentional. The _intended_ way to do aware arithmetic was always to convert to UTC, do the arithmetic, then convert back. [Lennart] We can't explicitly implement incorrect timezone aware arithmetic and then expect people to not use it. Python didn't implement timezone-aware arithmetic at all within a single time zone. Read what I wrote just above. It implements naive arithmetic within a single time zone. We can make the arithmetic correct, The naive arithmetic within a timezone is already correct, by its own internal criteria. It's also useful (see the original discussions, or Paul Moore's recent brief account). That it's not the arithmetic you want doesn't make it incorrect, it makes it different from what you want. That's fine - you're allowed to want anything ;-) But it's a dozen years too late to change that decision. Maybe for Python 4. and we can raise an error when doing tz-aware arithmetic in a non-fixed timezone. Sorry, I don't know what that means. Under any plausible interpretation, I don't see any need to raise an exception. But having an implementation we know is incorrect You really have to get over insisting it's incorrect. It's functioning exactly the way it was intended to function. It's _different_ from what you favor. Note that I'm not calling what you favor incorrect. It's different. Both kinds of arithmetic are useful for different purposes, although I still agree with Guido's original belief that the current arithmetic is most useful most often for most programmers. and telling people don't do that doesn't seem like a good solution here. We don't tell people don't do that. It's perfectly usable exactly as-is for many applications. Not all. For those applications needing the other kind of arithmetic, the convert-to/from-UTC dance was the intended solution. Why do we even have timezone aware datetimes if we don't intend them for usage? They are intended for usage. But a single way of using them is not suitable for all possible applications. ... Python's datetime never intended to support that directly. I think it should. Ya, I picked that up ;-) I don't, but it's too late to break backward compatibility regardless. It's expected that it supports it, By some people, yes. Not by all. and there is no real reason not to support it. Backward compatibility is a gigantic reason to continue with the status quo. See Paul Moore's post for a start on why naive arithmetic was picked to begin with. The timezone handling becomes complicated if you base yourself on localtime, and simple if you base yourself on UTC. That's an implementation detail unrelated (in principle) to how arithmetic works. Although as a practical matter it cuts both ways: naive local-time arithmetic is complicated if the internal time is stored in UTC, but simple if stored in local time. As you agree, we recommend to people to use UTC at all times, I recommend people don't use tzinfo at all if they can avoid it. Beyond that, there are many attractions to using UTC, and to explicitly use UTC. Not all applications need to care, though. and only use timezones for input and output. Well, what I'm now proposing is to take that recommendation to heart, and change datetime's implementation so it does exactly that. Suppose I'm correct in my belief that there's scant chance of getting approval for changing the default datetime arithmetic in Python 3 (or Python 2). Would you still be keen to replace the internals with UTC format? Note that there are many consequences to that implementation detail. For example, it was an explicit requirement of the datetime design that the month, day, hour, minute and second components be very cheap to extract. If you have to do conversion every time one is accessed, it's much slower; if you cache the local time components separately, the memory burden increases. Etc. I saw the previous mention of pure vs practical, and that is often a concern. Here it clearly is not. This is a choice between impure, complicated and impractical, and pure, simple and practical. There is nothing in the datetime world simpler than naive arithmetic ;-) Practical is relevant to a specific application's specific needs, and neither kind of arithmetic is practical for all applications. Guido believed naive arithmetic is most practical overall. But even believing that too, datetime certainly should be beefed up to solve the _other_ problems: like resolving ambiguous times, and supporting the full range of zoneinfo possibilities Is it the case that pytz also fails in the cases your attempts fail? No, that is not the case. And if you wonder why I just don't do it like pytz does it, it's because that leads to infinite recursion, much as discussions on this mailing list does. ;-) And this is because we need to normalize the
Re: [Python-Dev] Status on PEP-431 Timezones
On Mon, Jul 27, 2015 at 4:04 AM, Tim Peters tim.pet...@gmail.com wrote: Realistically, default arithmetic behavior can't change in Python 3 (let alone Python 2). Then we can't implement timezones in a reasonable way with the current API, but have to have something like pytz's normalize() function or similar. I'm sorry I've wasted everyones time with this PEP. //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
[Paul Moore p.f.mo...@gmail.com] As an example, consider an alarm clock. I want it to go off at 7am each morning. I'd feel completely justified in writing tomorrows_alarm = todays_alarm + timedelta(days=1). [Lennart Regebro rege...@gmail.com] That's a calendar operation made with a timedelta. It's an instance of single-timezone datetime arithmetic, of the datetime + timedelta form. Your examples have been of the same form. Note that after Paul's tomorrows_alarm = todays_alarm + timedelta(days=1) it's guaranteed that assert tomorrows_alarm - todays_alarm == timedelta(days=1) will succeed too. The days attribute here is indeed confusing as it doesn't mean 1 day, it means 24 hours. Which, in naive arithmetic, are exactly the same thing. That's essentially why naive arithmetic is the default: it doesn't insist on telling people that everything they know is wrong ;-) There's nothing confusing about Paul's example _provided that_ single-timezone arithmetic is naive. It works exactly as he intends every time, and obviously so. Seriously, try this exercise: how would you code Paul's example if your kind of arithmetic were in use instead? For a start, you have no idea in advance how many hours you may need to add to get to the same local time tomorrow. 24 won't always work Indeed, no _whole_ number of hours may work (according to one source I found, Australia's Lord Howe Island uses a 30-minute DST adjustment). So maybe you don't want to do it by addition. What then? Pick apart the year, month and day components, then simulate naive arithmetic by hand? The point is that there's no _obvious_ way to do it then. I'd personally strip off the tzinfo member, leaving a wholly naive datetime where arithmetic works correctly ;-) , add the day, then attach the original tzinfo member again. But for a dozen years it's sufficed to do what Paul did. ___ 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 9:09 AM, Tim Peters tim.pet...@gmail.com wrote: But for a dozen years it's sufficed to do what Paul did. No, it never did suffice. It's just that people have been doing various kinds of workarounds to compensate for these design flaws. I guess they need to continue to do that for the time being. //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 9:09 AM, Tim Peters tim.pet...@gmail.com wrote: It's an instance of single-timezone datetime arithmetic, of the datetime + timedelta form. No, because in that case it would always move 24 hours, and it doesn't. It sometimes moves 23 hours or 25 hours, when crossing a DST border. That is a calendar operation, in the disguise of a datetime arithmetic. But this discussion is now moot, if we can't change this, then we can't change this, and PEP431 is dead. The only reasonable way out if this mess is a completely new module for dates and times that doesn't make these kind of fundamental mistakes. I sincerely doubt I have the time to implement that this decade. //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 10:47 AM, Paul Moore p.f.mo...@gmail.com wrote: I'm confused by your position. If it's 7am on the clock behind me, right now, then how (under the model proposed by the PEP) do I find the datetime value where it will next be 7am on the clock? PEP-431 does not propose to implement calendar operations, and hence does not address that question. //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 11:05 AM, Paul Moore p.f.mo...@gmail.com wrote: Am I right to think that because you say implement calendar operations this is not, as far as you are aware, something that already exists in the stdlib (outside of datetime)? I'm certainly not aware of an alternative way of doing it. Right, I think you need to use relativedelta (or rrule) from dateutil, unless you want to do it yourself, which of course in most cases is quite easy. //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 27 July 2015 at 08:34, Lennart Regebro rege...@gmail.com wrote: On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters tim.pet...@gmail.com wrote: But for a dozen years it's sufficed to do what Paul did. No, it never did suffice. It's just that people have been doing various kinds of workarounds to compensate for these design flaws. I guess they need to continue to do that for the time being. I'm confused by your position. If it's 7am on the clock behind me, right now, then how (under the model proposed by the PEP) do I find the datetime value where it will next be 7am on the clock? I understand your point that it's a calendar operation, but that doesn't help me. I still don't know how you want me to *do* the operation. Whatever the outcome of this discussion, any PEP needs to explain how to implement this operation, because at the moment, it's done with +timedelta(days=1) and that won't be the case under the PEP. I'm not trying to shoot down your proposal here, just trying to understand it. 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 27 July 2015 at 09:54, Lennart Regebro rege...@gmail.com wrote: On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore p.f.mo...@gmail.com wrote: I'm confused by your position. If it's 7am on the clock behind me, right now, then how (under the model proposed by the PEP) do I find the datetime value where it will next be 7am on the clock? PEP-431 does not propose to implement calendar operations, and hence does not address that question. OK, I see. But it does propose to remove that operation from datetime. Thanks for the clarification. Am I right to think that because you say implement calendar operations this is not, as far as you are aware, something that already exists in the stdlib (outside of datetime)? I'm certainly not aware of an alternative way of doing it. 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
