Closed padamstx closed 3 years ago
Merging #87 (e133abb) into master (819e6dd) will not change coverage. The diff coverage is
100.00%
.
@@ Coverage Diff @@
## master #87 +/- ##
=======================================
Coverage 98.19% 98.19%
=======================================
Files 18 18
Lines 665 665
=======================================
Hits 653 653
Misses 12 12
Impacted Files | Coverage Δ | |
---|---|---|
ibm_cloud_sdk_core/utils.py | 99.19% <100.00%> (ø) |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 819e6dd...e133abb. Read the comment docs.
:tada: This PR is included in version 3.3.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Fixes arf/planning-sdk-squad#2313
This commit adds new tests for the datetime_to_string and string_to_datetime functions to ensure that each of the required date-time formats are supported. These new tests are aligned with similar tests in the Java and Go cores.
Edit: I originally included a change to datetime_to_string() to use only milliseconds precision when marshalling a datetime value, but it turns out that the python versions we build with on Travis do not support the use of the "timespec" parameter on the datetime.isoformat() function. So, I'll leave datetime_to_string() alone for now and it will continue to produce strings with microsecond precision, which leaves us no worse off than we were before. But the addition of the new tests should provide us with some confidence that we support the same formats of datetime values as in the Java and Go cores.