Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #523 +/- ##
==========================================
+ Coverage 78.10% 78.21% +0.10%
==========================================
Files 123 125 +2
Lines 11541 11790 +249
Branches 1748 1785 +37
==========================================
+ Hits 9014 9221 +207
- Misses 1817 1833 +16
- Partials 710 736 +26
🚀 New features to boost your workflow:
|
b1e9c8a to
25f17ea
Compare
25f17ea to
54e56b7
Compare
54e56b7 to
35b33d4
Compare
finnag
left a comment
There was a problem hiding this comment.
This deserves a little more thorough testing
| [InlineData("2020-01-01T01:00+01:00", false)] | ||
| [InlineData("2020-01-01T01+01:00", false)] | ||
| [InlineData("2020-01-01+00:00", false)] | ||
| [InlineData("2020-01-01Z", false)] |
There was a problem hiding this comment.
That was an extremely simplified list of tests?
In a good old test driven methology the winning implementation would be return DateTime(2020, 1, 1, 0, 0, 0, DateTimeKind.Utc) to satisfy all tests.
We should at least test that it parses the numbers in the right order (day/month/year/hour/minute/), that time zones work as intended, that bad dates do NOT parse, and so on.
There was a problem hiding this comment.
I added some more test cases, but there really is only so much value in testing a standard library function.
There was a problem hiding this comment.
@finnag I've updated this, it's ready for another risk review.
Add a timestampwrapper config utility, which should make this type easier to use in a good way in config. Make it accept RFC3339-like datetimes, but also shortened. We require a timezone, which IMO is a good idea, to avoid ambiguity.
35b33d4 to
d82c960
Compare
Add a timestampwrapper config utility, which should make this type easier to use in a good way in config.
Make it accept RFC3339-like datetimes, but also shortened. We require a timezone, which IMO is a good idea, to avoid ambiguity.