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
