Well, the interface for these values are currently class properties, otherwise we could just pass a flag along for tz awareness. I wasn't aware of the incompatibility between both so this does start to look messy.
On Wed, Nov 25, 2015 at 11:24 AM, Jean-Paul Calderone <jean-p...@clusterhq.com> wrote: > 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 > _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
