chrono

pening, you can see this looking at the underlying implementation: https://github.com/lifthrasiir/rust-chrono/blob/cf5e2f322fbc... (and tracking those functions calls through inside that module).

cs and a closure, neither of which ought to be necessary. Despite all this generality, there are two copies of this code, one for time-zone aware and one for "naive" timestamps. The author of that module has misgivings about the structure. He writes "This is a bit verbose due to Rust's lack of function and method overloading, but in turn we get a rich combination of initialization methods." This is the best of the three date-time modules available; the other two won't even compile with the current build system and are abandoned. There are some neat ideas in the type system. One is that if you have something which might not be able to return a value, you have it return an "Option<T>" value, which can have a value of type T, or a value of None. Sorting out what was returned requires a "match" statement, which is rather verbose. It's an elegant way to avoid null pointers and error codes, but it's quite verbose in practice. The business with "and_then" and the closure above is to deal with that problem. See "Option Monads in Rust" ("http://www.hoverbear.org/2014/08/12/option-monads-in-rust/") for an explanation. In Python, situations like this raise a ValueError exception. In Go, situations like this return (uselessvalue, err). The Rust solution is formally correct, but complex and verbose for what it's doing. I'm worried that all this verbiage will turn new users off. It turns me off, and I have a background in formal systems.