mirror-github-bspeice/dtparse
1
0
Fork 0
mirror of https://github.com/bspeice/dtparse synced 2024-12-22 04:18:09 -05:00
Code Issues Releases Wiki Activity

Get the README updated with what's needed before 1.0

Browse Source
This commit is contained in:
Bradlee Speice 2018-06-17 23:21:11 -04:00
parent 7d565d3a78
commit e54977ee97
2 changed files with 22 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Cargo.toml
View File

@ -1,7 +1,7 @@
[package] [package]
name = "dtparse" name = "dtparse"
version = "0.1.0" version = "0.7.0"
authors = ["Bradlee Speice <bspeice@kcg.com>"] authors = ["Bradlee Speice <bradlee@speice.io>"]
[dependencies] [dependencies]
chrono = "0.4" chrono = "0.4"

23
README.md
View File

@ -3,7 +3,24 @@ A [dateutil](https://github.com/dateutil/dateutil)-compatible timestamp parser f
## Where it stands ## 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 The issues to be resolved before version 1.0:
a compatible parser can be built.
**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.