-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start date explicit timezone to UTC for all files #210
Start date explicit timezone to UTC for all files #210
Conversation
Signed-off-by: Mikael Arguedas <[email protected]>
This reverts commit fb80485. Signed-off-by: Mikael Arguedas <[email protected]>
Signed-off-by: Mikael Arguedas <[email protected]>
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.
|
@@ -80,7 +80,7 @@ def build_key_and_cert(subject_name, *, ca=False, ca_key=None, issuer_name=''): | |||
else: | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)