Start date explicit timezone to UTC for all files#210
Start date explicit timezone to UTC for all files#210mikaelarguedas wants to merge 3 commits intoros2:masterfrom
Conversation
Signed-off-by: Mikael Arguedas <mikael.arguedas@gmail.com>
This reverts commit fb80485. Signed-off-by: Mikael Arguedas <mikael.arguedas@gmail.com>
Signed-off-by: Mikael Arguedas <mikael.arguedas@gmail.com>
4946465 to
897b112
Compare
Codecov Report
@@ Coverage Diff @@
## master #210 +/- ##
==========================================
+ Coverage 77.95% 77.98% +0.03%
==========================================
Files 16 16
Lines 576 577 +1
Branches 52 52
==========================================
+ Hits 449 450 +1
Misses 107 107
Partials 20 20
Continue to review full report at Codecov.
|
| extension = x509.BasicConstraints(ca=False, path_length=None) | ||
|
|
||
| utcnow = datetime.datetime.utcnow() | ||
| utcnow = datetime.datetime.now(datetime.timezone.utc) |
There was a problem hiding this comment.
Note: the changes to the certificates (so here and in test_create_key.py) have no effect as the datetime used by python cryptography are considered naive and UTC. I added the UTC awareness just for consistency and in case cryptography supports timezones in the future
|
Yeah assuming this solves the issue I like this approach a lot better. |
|
Tests failed on mini1 :(
I've been manually testing on Output from one of the failing tests And the <validity>^M
<not_before>2020-05-07T15:58:26+00:00</not_before>^M
<not_after>2030-05-05T15:58:26+00:00</not_after>^M
</validity>^M |
|
no way! that's a shame :( Well then I suggest to put this on standby and merge #209 to fix the nightlies |
|
CLosing as not fixing the issue. Issue now tracked at #211 |
Less hacky atlernative to #209
@sloretz I don't know how to test this, could you please give this a round of CI to see if it works with ros2/ci#436 ?
One linux test at https://ci.ros2.org/job/ci_linux/10646, (actually not a useful test because ros2/system_tests#415 is far behind master)