Add timezones parsing #123
Conversation
|
Sorry for the very long delayed response on this. I think this should be included, even with the additional dependency. Seems like I'm the only maintainer of this package even though I never use it 🤦. If you can rebase onto |
|
Awesome, no worries! Just rebased. The test run well locally, though it looks like they aren't running here - let me know if there's anything I need to do to get that running. Thanks for checking this out! |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #123 +/- ##
=======================================
Coverage 86.46% 86.46%
=======================================
Files 12 12
Lines 1625 1626 +1
=======================================
+ Hits 1405 1406 +1
Misses 220 220
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
|
Looks great! Going to merge. I think I'll make a minor version release with #130 , and then a major release with this since it's a new feature / adds a dependency. |
| delta_mn = parse(Int, mat.captures[10]) | ||
|
|
||
| if mat.captures[8] === nothing | ||
| return DateTime(yr, mn, dy, h, m, s, ms) |
There was a problem hiding this comment.
Actually - before we merge, I wonder about this - it makes the function not type-stable. Should this also be a ZonedDateTime, but just with UTC?
In any case, we should have a test case that hits this line I think
There was a problem hiding this comment.
Good idea! Nice that codecov shows it isn't currently tested. Any idea what the test should be? The other tests are taken exactly form the spec (here) so we'd have to make up a line that has time and date but no timezone.
I'm torn on what to do about the DateTime vs ZonedDateTime thing... I think DateTime is used a lot more, and it is useful even without timezones. Dates.now(), for example, shows my local system time. If I wrote a YAML document and specified times with no consideration for timezone, I don't know if I'd want to the read to assume it was all UTC. ZonedDateTimes are definitely a safer choice though. Unfortunately I don't think the spec makes a clear choice so we'll have to pick an implementation ourselves.
Adds timezones for DateTime parsing! This is accomplished through the use of the TimeZones.jl package. The tests in test/spec-02-22.expected had to be updated to output
ZonedDateTimeobjects instead ofDateTimeobjects, but I think this change better reflects the strictly time-zoned nature of the input strings (like2001-12-15T02:59:43.1Zand2001-12-14t21:59:43.10-05:00).One question I have for the maintainers - should IANA timezone names like
America/New_Yorkbe implemented? I don't see mention of them in the YAML spec, but TimeZones.jl supports them and it might be a nice addition.