From e54977ee97848b49a322d60acb346ac9b8ce9cd8 Mon Sep 17 00:00:00 2001 From: Bradlee Speice Date: Sun, 17 Jun 2018 23:21:11 -0400 Subject: [PATCH] Get the README updated with what's needed before 1.0 --- Cargo.toml | 4 ++-- README.md | 23 ++++++++++++++++++++--- 2 files changed, 22 insertions(+), 5 deletions(-) diff --git a/Cargo.toml b/Cargo.toml index 08d86f8..7e3220d 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -1,7 +1,7 @@ [package] name = "dtparse" -version = "0.1.0" -authors = ["Bradlee Speice "] +version = "0.7.0" +authors = ["Bradlee Speice "] [dependencies] chrono = "0.4" diff --git a/README.md b/README.md index ed300c0..1ddb1e6 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,24 @@ A [dateutil](https://github.com/dateutil/dateutil)-compatible timestamp parser f ## Where it stands -Currently, most of the non-timezone functionality is complete (absent a couple of failing test cases that use fractional minutes). +The library works really well at the moment, and passes the vast majority of `dateutil`s parser +test suite. This isn't mission-critical ready, but is more than ready for hobbyist projects. -Timezone support in Rust right now is a [bit limited](https://github.com/chronotope/chrono-tz), but should be enough that -a compatible parser can be built. +The issues to be resolved before version 1.0: + +**Functionality**: + +1. We don't support weekday parsing. In the Python side this is accomplished via `dateutil.relativedelta` + +2. Named timezones aren't supported very well. [chrono_tz](https://github.com/chronotope/chrono-tz) +theoretically would provide support, but I'd also like some helper things available (e.g. "EST" is not a named zone in `chrono-tz`). +Explicit time zones (i.e. "00:00:00 -0300") are working as expected. + +3. "Fuzzy" and "Fuzzy with tokens" modes haven't been tested. The code should work, but I need to get the +test cases added to the auto-generation suite + +**Non-functional**: This library is intended to be a direct port from Python, and thus the code +looks a lot more like Python than it does Rust. There are a ton of `TODO` comments in the code +that need cleaned up, things that could be converted to enums, etc. + +In addition, some more documentation would be incredibly helpful. It's, uh, sparse at the moment.