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

[Jean-Paul Calderone]

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 <donald at 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.kehrer at 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.trauschke at 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.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
> >
> _______________________________________________
> 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
>
>
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20151125/77c07721/attachment.html>