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 > <mailto: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 <mailto:Cryptography-dev@python.org> > https://mail.python.org/mailman/listinfo/cryptography-dev > <https://mail.python.org/mailman/listinfo/cryptography-dev> ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
