For example, this time can be returned:

2016-08-06 11:59:52.018000+00:00

Instead of:

2016-08-06 11:59:52.180000+00:00

A detailed analysis can be found here:

ralphje/signify#45

Sorry that this has taken so long to investigate, but the issue is clearly somewhere in pyasn1 code. We use the conversion in the asDateTime method as provided by pyasn1, as shown here.

In the case of your example, the relevant GeneralizedTime object of the TSTInfo object is as follows:

>>> list(pe.signed_datas)[0].signer_info.countersigner.tst_info.data["genTime"]
<GeneralizedTime value object, tagSet <TagSet object, tags 0:0:24>, encoding us-ascii, payload [20160806115952.18Z]>

From the method defined here in pyasn1, it seems that the code assumes a certain number of decimals after the decimal separator (as it multiplies by 1000). In the case of your provided sample, it is clear that there are only 2 decimals provided. You're welcome to open an issue over there, referencing this issue.

However, switching to asn1crypto seems to have resolved this issue for us. The relevant part of that library takes a variable number of decimals into account.

I have added a test that should mark this as an issue in the future. The test fails on 0.6.1 and succeeds on master.