Re: [Python-Dev] Python3 Stable ABI

I don't see any obvious issues, but there may be some that don't need to be marked stable. Given that a mismatch here will cause build errors for users, I'm +1 on checking this in. Cheers, Steve Top-posted from my Windows Phone From: Zachary Ware

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

On 15-04-15, Akira Li <4kir4...@gmail.com> wrote: > Isaac Schwabacher writes: > > > On 15-04-15, Akira Li <4kir4...@gmail.com> wrote: > >> Isaac Schwabacher writes: > >> > ... > >> > > >> > I know that you can do datetime.now(tz), and you can do datetime(2013, > >> > 11, 3, 1, 30, tzinfo=zoneinf

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

Isaac Schwabacher writes: > On 15-04-15, Akira Li <4kir4...@gmail.com> wrote: >> Isaac Schwabacher writes: >> > ... >> > >> > I know that you can do datetime.now(tz), and you can do datetime(2013, >> > 11, 3, 1, 30, tzinfo=zoneinfo('America/Chicago')), but not being able >> > to add a time zone

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

On Wed, Apr 15, 2015 at 5:28 PM, Stuart Bishop wrote: > > On 15 April 2015 at 21:51, Lennart Regebro wrote: > > On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop wrote: > > > Just punting it to tzinfo to make adjustments, ie effectively just > > doing what normalize() does creates infinite recursio

Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones

On Wed, Apr 15, 2015 at 4:46 PM, Akira Li <4kir4...@gmail.com> wrote: > > Look what happened on July 1, 1990. At 2 AM, the clocks in Ukraine were > > moved back one hour. So times like 01:30 AM happened twice there on that > > day. Let's see how Python handles this situation > > > > $ TZ=Europe

Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones

Alexander Belopolsky writes: > ... > For most world locations past discontinuities are fairly well documented > for at least a century and future changes are published with at least 6 > months lead time. It is important to note that the different versions of the tz database may lead to different

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

On 15 April 2015 at 21:51, Lennart Regebro wrote: > On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop > wrote: > Just punting it to tzinfo to make adjustments, ie effectively just > doing what normalize() does creates infinite recursion as there is > more arithmetic in there, so it's not quite tha

Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones

Alexander Belopolsky writes: > Sorry for a truncated message. Please scroll past the quoted portion. > > On Thu, Apr 9, 2015 at 10:21 PM, Alexander Belopolsky < > alexander.belopol...@gmail.com> wrote: > >> >> On Thu, Apr 9, 2015 at 4:51 PM, Isaac Schwabacher >> wrote: >> >>> > > > Well, you ar

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

On 15-04-15, Akira Li <4kir4...@gmail.com> wrote: > Isaac Schwabacher writes: > > ... > > > > I know that you can do datetime.now(tz), and you can do datetime(2013, > > 11, 3, 1, 30, tzinfo=zoneinfo('America/Chicago')), but not being able > > to add a time zone to an existing naive datetime is pai

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

Isaac Schwabacher writes: > ... > > I know that you can do datetime.now(tz), and you can do datetime(2013, > 11, 3, 1, 30, tzinfo=zoneinfo('America/Chicago')), but not being able > to add a time zone to an existing naive datetime is painful (and > strptime doesn't even let you pass in a time zone)

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

Lennart Regebro writes: > OK, so I realized another thing today, and that is that arithmetic > doesn't necessarily round trip. > > For example, 2002-10-27 01:00 US/Eastern comes both in DST and STD. > > But 2002-10-27 01:00 US/Eastern STD minus two days is 2002-10-25 01:00 > US/Eastern DST "two

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

Alexander Belopolsky writes: > On Wed, Apr 8, 2015 at 3:57 PM, Isaac Schwabacher > wrote: >> >> On 15-04-08, Alexander Belopolsky wrote: >> > With datetime, we also have a problem that POSIX APIs don't have to > deal with: local time >> > arithmetics. What is t + timedelta(1) when t falls on the

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

On Thu, Apr 16, 2015 at 1:43 AM, Lennart Regebro wrote: > On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico wrote: >> Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be >> more logical to describe it as "adding six hours means adding six >> hours to the UTC time", but it'd look

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

On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop wrote: > Huh. I didn't think you would need to change any arithmetic Not really, the problem is in keeping the date normalized after each call, and doing so the right way. > Arithmetic > remains 'add the timedelta to the naive datetime, and then pun

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

On 15 April 2015 at 17:00, Lennart Regebro wrote: > OK, so I just had a realization. > > Because we want some internal flag to tell if the datetime is in DST > or not, the datetime pickle format will change. And the datetime > pickle format changing is the biggest reason I had against changing > t

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

On 15-04-15, Lennart Regebro wrote: > On Wed, Apr 15, 2015 at 12:40 PM, Isaac Schwabacher > wrote: > > I am on the fence about EPOCH + offset as an internal representation. On > > the one hand, it is conceptually cleaner than the horrible byte-packing > > that exists today, but on the other han

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

On Wed, Apr 15, 2015 at 12:40 PM, Isaac Schwabacher wrote: > I am on the fence about EPOCH + offset as an internal representation. On the > one hand, it is conceptually cleaner than the horrible byte-packing that > exists today, but on the other hand, it has implications for future > implementa

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

On 15-04-15, Lennart Regebro wrote: > On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico wrote: > > Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be > > more logical to describe it as "adding six hours means adding six > > hours to the UTC time", but it'd look extremely odd whe

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

On Wed, Apr 15, 2015 at 11:43 AM, Lennart Regebro wrote: > On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico wrote: >> Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be >> more logical to describe it as "adding six hours means adding six >> hours to the UTC time", but it'd look

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

On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico wrote: > Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be > more logical to describe it as "adding six hours means adding six > hours to the UTC time", but it'd look extremely odd when there's a > leap second. It would ignore l

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

On Thu, Apr 16, 2015 at 1:00 AM, Lennart Regebro wrote: > So because of this, perhaps we actually *should* change the internal > representation to UTC, because that makes the issues I'm fighting with > now so much simpler. (I'm currently trying to get arithmetic to do the > right thing in all case

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

OK, so I just had a realization. Because we want some internal flag to tell if the datetime is in DST or not, the datetime pickle format will change. And the datetime pickle format changing is the biggest reason I had against changing the internal representation to UTC. So because of this, perhap

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

Yeah, I just realized this. As long as you use timedelta, the difference is of course not one day, but 24 hours. That solves the problem, but it is surprising in other ways. In US/Eastern datetime.datetime(2002, 10, 27, 1, 0) - datetime.timedelta(1) needs to become datetime.datetime(2002, 10, 26,