Re: [Python-Dev] Status on PEP-431 Timezones

On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters wrote: > [Tim] >>> timedelta objects only store days, seconds, and microseconds, > > [Lennart Regebro ] >> Except that they don't actually store days. They store 24 hour >> periods, > > Not really. A timedelta is truly an integer number of microseconds,

Re: [Python-Dev] Status on PEP-431 Timezones

[Tim] >> timedelta objects only store days, seconds, and microseconds, [Lennart Regebro ] > Except that they don't actually store days. They store 24 hour > periods, Not really. A timedelta is truly an integer number of microseconds, and that's all. The internal division into days, seconds and

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, coo

Re: [Python-Dev] Status on PEP-431 Timezones

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". :-) //Lennart __

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

Re: [Python-Dev] Status on PEP-431 Timezones

On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence 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

Re: [Python-Dev] Status on PEP-431 Timezones

On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren 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 > transi

Re: [Python-Dev] Status on PEP-431 Timezones

On Tue, Jul 28, 2015 at 12:03 AM, Tim Peters 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 timed

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 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 yea

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" 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 clea

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

Robert Collins writes: > On 21 July 2015 at 00:34, Ben Finney wrote: > > Paul Moore 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

Re: [Python-Dev] Status on PEP-431 Timezones

Paul Moore writes: > On 27 July 2015 at 15:57, Ronald Oussoren 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

Re: [Python-Dev] Status on PEP-431 Timezones

[Mark Lawrence ] > 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 >

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

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(hou

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 z

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) > >

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 2:10 PM, Tim Peters 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 t

[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.pytho

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 l

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 12:47 PM, Ethan Furman 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 t

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 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 s

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 inte

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 5:13 PM, Tim Peters wrote: > [Brett Cannon ] > \> 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 tha

Re: [Python-Dev] Status on PEP-431 Timezones

> On 27 jul. 2015, at 20:49, Tim Peters wrote: > > [Ronald Oussoren ] >> 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 arithm

Re: [Python-Dev] Status on PEP-431 Timezones

[Tres Seaver ] > "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 confir

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 (tho

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 (ak

Re: [Python-Dev] Status on PEP-431 Timezones

On 27 July 2015 at 22:10, Tim Peters 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" bi

Re: [Python-Dev] Status on PEP-431 Timezones

[Brett Cannon ] \> 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:

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 8640

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 > re

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 7:49 AM Lennart Regebro wrote: > On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan wrote: > > On 28 July 2015 at 00:27, Steve Dower 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

Re: [Python-Dev] Status on PEP-431 Timezones

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

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 ] > This usage of "time zone" is confusing. Ha! _All_ usages of "time zone" are confusing ;-)

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 tomor

Re: [Python-Dev] Status on PEP-431 Timezones

[Terry Reedy ] > 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

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

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 sear

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 ] > No leap second support, presumably. Also feature? Absolutely none, and absolutely "a feature", but

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 12:07 PM, Chris Angelico 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. -CH

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 11:55 AM, Terry Reedy wrote: > I think using the word 'naive' is both inaccurate and a mistake. > > '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

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

Re: [Python-Dev] Status on PEP-431 Timezones

On Tue, Jul 28, 2015 at 4:49 AM, Tim Peters 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 ___

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 _

Re: [Python-Dev] Status on PEP-431 Timezones

On 7/27/2015 3:09 AM, Tim Peters wrote: [Paul Moore ] 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 ] That's a calendar operation made with a t

Re: [Python-Dev] Status on PEP-431 Timezones

[Ronald Oussoren ] > 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 i

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

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 t

Re: [Python-Dev] Status on PEP-431 Timezones

On Tue, Jul 28, 2015 at 12:57 AM, Ronald Oussoren 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 bikeshi

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 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 exper

Re: [Python-Dev] Status on PEP-431 Timezones

> On 27 Jul 2015, at 04:04, Tim Peters 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

Re: [Python-Dev] Status on PEP-431 Timezones

On 27 July 2015 at 15:57, Ronald Oussoren 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).

Re: [Python-Dev] Status on PEP-431 Timezones

On 27 July 2015 at 17:30, Lennart Regebro 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? > >

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 6:42 PM, Alexander Belopolsky 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-

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro wrote: > On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath wrote: > > On Jul 27 2015, Lennart Regebro 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 d

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 wrote: On 26 July 2015 at 16:39, Berker PeksaÄŸ 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 :)

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 12:15 PM, Nikolaus Rath wrote: > On Jul 27 2015, Lennart Regebro 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 t

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath wrote: > On Jul 27 2015, Lennart Regebro 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

Re: [Python-Dev] Status on PEP-431 Timezones

On Jul 27 2015, Lennart Regebro 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 th

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert 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

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore 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

Re: [Python-Dev] Status on PEP-431 Timezones

> On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky > 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

Re: [Python-Dev] Status on PEP-431 Timezones

On 27 July 2015 at 16:26, MRAB 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 representatio

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 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 app

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 5:12 PM, Paul Moore 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 thin

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 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

Re: [Python-Dev] Status on PEP-431 Timezones

On 27 July 2015 at 15:37, Lennart Regebro 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 i

Re: [Python-Dev] Status on PEP-431 Timezones

> On Jul 27, 2015, at 9:13 AM, Steven D'Aprano 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 wrote: >>> I'm confused by your position. If it's 7am on the clock behind me, >>> right now, then how (under the model propo

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 th

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, 27 Jul 2015 16:37:47 +0200, Lennart Regebro wrote: > On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray > 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

Re: [Python-Dev] Status on PEP-431 Timezones

On 27 July 2015 at 14:59, R. David Murray 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 com

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan wrote: > On 28 July 2015 at 00:27, Steve Dower 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

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 4:27 PM, Steve Dower 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.

Re: [Python-Dev] Status on PEP-431 Timezones

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 wording

Re: [Python-Dev] Status on PEP-431 Timezones

On 28 July 2015 at 00:27, Steve Dower 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

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray 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

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'Aprano Sent: ‎7/‎27/‎2015 7:14 To: python-dev@python.org Subj

Re: [Python-Dev] Status on PEP-431 Timezones

On Tue, Jul 28, 2015 at 12:13 AM, Steven D'Aprano 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 wrote: >> > I'm confused by your position. If it's 7am on the clock behind me, >> > right now, then how (under the model prop

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 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

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, 27 Jul 2015 02:09:19 -0500, Tim Peters 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". 2

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 > >> arithm

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 11:05 AM, Paul Moore 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.

Re: [Python-Dev] Status on PEP-431 Timezones

On 27 July 2015 at 09:54, Lennart Regebro wrote: > On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore 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 th

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore 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 calenda

Re: [Python-Dev] Status on PEP-431 Timezones

On 27 July 2015 at 08:34, Lennart Regebro wrote: > On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters 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 fla

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters 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

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters 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

Re: [Python-Dev] Status on PEP-431 Timezones

[Paul Moore ] >> >> 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 ] > That's a calendar operation made with a timedelta. It's an instance of