Todo

TODO

"Not Yet Implemented" (NYI) and "Out of Scope" (OoS) features

NYI: Ambiguous units—namely months and years—as they cannot be unambiguously translated into days or seconds so would require special options for how to handle them, at least one of which would entail relative time support.
NYI: Non-English language support, but there is some rudimentary localization support in the parser's number handling.
NYI: speed and memory optimization. No testing has been done so far.
NYI: Perfect backwards compatibility with TimeSpan.Parser. It's pretty close.
NYI: parse uncommon SI units/prefixes like decaseconds, kiloseconds, megaseconds, gigaseconds, megadays, etc (Note: already parses milliseconds to picoseconds)
NYI: parse numbers written as words (e.g. "five minutes", "one second", "an hour", "500 trillion nanoseconds", "half a day"), also "Chinese numbers"
NYI: parse ISO 8601 time interval support e.g. P0DT2H30M
NYI: parse key:value pairs, e.g. "minutes:30, seconds:10" or "minutes=30"
NYI: parse number+format "5:10 [mm:ss]"
NYI: throw an exception on slash, e.g. 20/sec
NYI: parse fractional units: 1/2 hour, ½ minute
~~NYI:~~ explicitly accept slashy and parensy plurals, e.g. 20 sec/s or 2 second(s) — already works fine, but could be explicit for use with future strict parsing modes
NYI: parse 0 frames (video editing) 「00:00:00;00」NTSC
honor DateTimeFormat.MaxSecondsFractionDigits ?

PRs welcome for any of these missing features.

Road map (short/medium term)

~~TODO: Raise identical exceptions to TimeSpan.Parse(), and do it in identical scenarios. (e.g. Overflow for timespans which are just the right amount smaller than the tick size)~~ See: underflow
TODO: Internationalization — Cover all the cultures which TimeSpan.Parse() does. Should be straight forward as there's only small variations: the decimal separator in the seconds, which can be a period (.) or comma (,) or slash (/); and the separator between the days and hours: a period (.) in the common "c" format, and a colon (:) in all others. However, we support more than just TimeSpan.Parse()'s input. [note: Even if the localization is set to French (comma decimal separator in the seconds), the "common" format should still parse successfully. This is the main thing missing for i18n right now.]
TODO: Full tests with coverage for all parser settings (and get them all to pass)
TODO: Better handling of unknown text tokens in the input (largely ignored currently)
TODO: make UnitTests use the invariant localization (for when localization is complete)

Blue Sky Features Anything in this list is verging on being out-of-scope for the project.

Relative time support — e.g. "until next thursday" is not supported and currently no plans to add support. See Pathoschild/NaturalTimeParser, nChronic, and Microsoft LUIS if you need this now.
Parse languages other than English. e.g. Support for Humanizer resx and/or CLDR
Find TimeSpans within a larger text and return their locations
Output anything other than a TimeSpan. e.g. integer seconds, nanoseconds (as used by protobuff, golang, NodaTime.Duration and this thing), flicks, a moment.duration (months + milliseconds), a NodaTime.Period (4 ints + 6 longs), a Python timedelta object (days, seconds, microseconds), a Swift TimeInterval (seconds in a double), a java.time.Duration (seconds + nanoseconds), a Rust duration (seconds + nanoseconds), a std::chrono::duration (a class template which lets you count with any numeric type and in any time interval imaginable as long as it's seconds), or a Scala duration (int/long/double ticks + tick unit) — create an issue if you have a usage case that would require something other than TimeSpan output, or think TimeSpanParser should roll its own.
TimeSpan operations, e.g. rounding
Leap second handling
Stable parsing. While still in development, TimeSpanParser is not guaranteed to have identical behavior between versions. Options may change too. In particular, TimeSpanParserOptions is evolving. [TODO: a best-practice guide]
Extended Date/Time Format (EDTF) support, if useful