Rfcs: Create a more robust date/time crate

[steveklabnik]

Issue by brson
_Wednesday Jun 04, 2014 at 22:11 GMT_

_For earlier discussion, see https://github.com/rust-lang/rust/issues/14657_

_This issue was labelled with: A-libs, I-enhancement in the Rust repository_

---

Just clone JodaTime. Start out of tree.

[jsanders]

Does chrono fulfill this? If not, what is missing?

[lifthrasiir]

cc me.

@jsanders The current issue items for Chrono exactly list them. In particular, parsing and versatile time zone support is the next big thing.

[jsanders]

@lifthrasiir Gotcha. Is the idea that chrono would eventually be merged into the standard library?

[John-Nagle]

It's a good candidate for the standard library. Better than the other alternatives:

"https://github.com/depp/datetime-rs" isn't packaged as a Cargo crate, so it's not importable.
"https://github.com/luisbg/rust-datetime" isn't packaged as a Cargo crate.
"https://github.com/rust-lang/rust/wiki/Lib-datetime" is discussion without any conclusions or actions.

Chrono has most of what you need on the data format, calculation and output side. It lacks any string parsing functions. How much more effort should go into obscure time zone problems and leap seconds is not clear.

We definitely need a standard representation of date and time in the standard library. Additional functions to operate on it can always be added.

[brson]

Just dropping this here http://www.reddit.com/r/rust/comments/36v4dz/practical_c_stl_concepts_and_ranges_the_calendar/ because the thread mentions something cool C++ can do with calendars.

[briansmith]

IMO, the chrono library is nice but it is too large to include in the standard library. I'd like to suggest that we create a library that allows for (just) the following:

• Convert a time given in YYYY-MM-DD:HH:mm:ss[+ZZ:zz] components to a std::time::SystemTime.
• Compare a < b ± ε, where a and b are SystemTimes.

These features are the minimum needed for many applications, in particular Web PKI X.509 TLS certificate validation. In the case of certificate validation, having a very narrowly targeted API, that can be exhaustively tested and/or even formally proved correct is very important. Additional features are a significant net negative.

I believe a lot of functionality of a more full-featured crate like rust-chrono could be built on top of this. Right now, we can get that functionality from the time crate, but it is awkward because the time crate is deprecated, and so we look like we don't know what we're doing if we do that. But, switching to the chrono crate doesn't actually make anything better, because it itself depends on the time crate, so it's actually just adding complexity for the applications that need just this minimum functionality.

I am thinking about creating a new crate that is just this functionality, probably by subsetting the time crate. But, I am curious if there is any interest in the Rust libs team in working towards some kind of standard API for this minimal functionality.

I think it's good to focus on a very narrow API because it is truly an enormous amount of work to create something like the new C++ API or Java's (new or old) API, and I think it might be a long time before something like that becomes stable.

[briansmith]

Compare a < b ± ε, where a and b are SystemTimes.

If I undrstand correct, this is how one could compare a certificate's validity range to the current time:

let now = SystemTime::now();-
let notBefore = <some way of constructing a SystemTime from its YYYY-MM-DD:HH:mm:ss[+ZZ:zz]>;
let notAfter = <some way of constructing a SystemTime from its YYYY-MM-DD:HH:mm:ss[+ZZ:zz]>;

/// XXX It would be better to do this by comparing the
/// YYYY-MM-DD:HH:mm:ss components pairwise.
if notBefore > notAfter {
   return Err(...);
}

let epsilon = Duration::from_secs(60 * 60 * 24); // 1 day.
if now + epsilon < notBefore {
    return Err(...);
}
if now - epsilon > notAfter {
    return Err(...);
}

So the only thing missing for certificate validation, at least, is a way to convert a Tm struct to a SystemTime.

[briansmith]

So the only thing missing for certificate validation, at least, is a way to convert a Tm struct to a SystemTime

Actually, I was wrong about this too. As the documentation states, one can construct a Duration from a a Tm-like struct by converting YYYY-MM-DD:HH:mm:ss UTC to seconds and then using Duration::from_secs and then adding the Duration to std::time::UNIX_EPOCH. This can all be done in a platform-independent manner, since std::time::UNIX_EPOCH is required to be in UTC. Actually, I had previously written some C++ code (mozilla::pkix) that worked exactly that way! Here's a rough prototype of what is required for the conversion: https://github.com/briansmith/webpki/commit/3f3cd95191d2112786a9c082f7e21d60e5e5819e

Thus, the current state of things is fine for me. Sorry for the noise.

[Centril]

I think this issue has outlived its usefulness; no movement in 2 years and there are crates for this.