[Cryptography-dev] Should datetime objects returned by not_valid_before, etc contain timezone info?

[Erik Trauschke]

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.kehrer at 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.trauschke at 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 at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>