The inability to compare naive and aware datetimes is an incompatibility. It is also exactly the reason you want these to be aware, of course. :)
I suggest this is worth doing but worth doing in a way that's backwards compatible. Introduce a new API for getting the aware datetime and deprecate the old one? On Wed, Nov 25, 2015 at 2:04 PM, Donald Stufft <don...@stufft.io> wrote: > This would be a backwards incompatible change FWIW because you can’t > compare a naive datetime against an aware datetime. > > On Nov 25, 2015, at 1:56 PM, Paul Kehrer <paul.l.keh...@gmail.com> wrote: > > I definitely can't claim to be an expert on tzinfo in Python, but if we > can define our own UTC timezone and have it be compatible with py3 UTC > objects that seems reasonable. Are there any surprises we should be aware > of? > > -Paul > > On November 25, 2015 at 11:27:27 AM, Erik Trauschke ( > erik.trausc...@gmail.com) wrote: > > As I see it this would be good practice since the timezone is properly > defined. I stumbled over it because the code I'm porting asserts that > the times we get are UTC so they can be compared correctly to the > current time. > > I guess you could just refer to the documentation but at the moment I > don't think it is explicitly mentioned anyway. It just takes the > guesswork out. > > Erik > > On Wed, Nov 25, 2015 at 8:39 AM, Paul Kehrer <paul.l.keh...@gmail.com> > wrote: > > The documentation states that these are naïve datetimes representing UTC, > > but it is true that you can't tell by introspecting the object itself. Do > > you see a significant advantage to attaching an explicit timezone to them > > outside of being able to introspect the return value in a REPL and see > that > > it's UTC? > > > > -Paul > > > > On November 25, 2015 at 9:57:40 AM, Erik Trauschke > > (erik.trausc...@gmail.com) wrote: > > > > I noticed that when ever we return datetime objects which come out of > > backend.py`_parse_asn1_time(), they don't have a tzinfo attached. > > > > Afaik, these values should always be UTC but for someone consuming > > just the result of not_valid_before, etc. that might not be clear. I > > think it should be possible to add this to _parse_asn1_time() so that > > we indicate that these are UTC times. > > > > I know it's a bit painful in Python <3.2 because we have to implement > > the tzinfo class ourself but it's also not that much code. > > > > Erik > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev@python.org > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev@python.org > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev@python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev@python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev@python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > >
_______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
