Relation to chrono

[Diggsey]

For a long time this crate was essentially deprecated, and most of the ecosystem now uses the chrono crate.

However, with 0.2 it looks like this crate has a new lease of life. It would be good to clarify the relationship of this crate with chrono, by giving examples of when someone would choose time vs chrono.

It would also be helpful to have interop between the two crates.

[jhpratt]

Pulling some info from #190:

Chrono has been the de facto crate for time management for quite a while. Like time, its original implementation predates rust 1.0. Presumably due to its age, chrono still relies on time v0.1 (though it's partially inlined the relevant code). The disadvantage of this is that any third-party functions that rely on chrono essentially mandate you import chrono or time v0.1 to use its Duration type. This single fact makes interoperability with the standard library quite difficult. Time v0.1 is identical to chrono in this manner.

Time v0.1 is what the standard library was built upon. Time v0.2 flips this, being built upon the standard library. This provides for a higher-level abstraction, while also supporting the same targets as the standard library.

In time v0.2, there is full interoperability with the standard library. Every type can perform the same arithmetic that its standard library counterpart can and vice versa. Types are freely convertible to and from their standard library equivalents.

This was also in the repo's wiki, but I disabled that recently because I never bothered to keep it up to date.

As to interoperability with chrono, that seems unlikely, given the APIs are significantly different. Much of time's code requires knowledge of internals; I presume chrono is the same way. Chrono is free to rely on time 0.2, though they've previously indicated that they will not do so.