So Chrono 0.3.0, a much delayed major version of Rust date and time library, is here. Update and watch your build breaking Enjoy.

Breaking Changes

I have described all changes to the changelog but the recent issue seems to indicate that it is not enough. So the following is the list of breaking changes primarily relevant to the users.

Rust 1.13.0 or later is required. As we have moved to Serde 0.9, we have bumped the minimal supported version to 1.13.0. It is possible to use Chrono on older versions with or without Serde (previously 1.8.0 was the minimal, and Serde 0.9 seems to work well with 1.12.0) but they are no longer supported now.

The subtraction between two time instants/points is gone. You should use a.signed_duration_since(b) instead of a - b . As you can expect, this name is very similar to the standard library’s one, but returns time::Duration instead of std::time::Duration . The proper name, duration_since has been reserved for the transition. (As aside, I don’t think that the subtraction operator in this case will return. It is very awkward to return Result<Duration, NegativeDuration> from an operator, and risking the panic every time one subtract two normal points seems to be unreasonable.) I don’t know if these methods are used a lot, but checked_{add,sub} and overflowing_{add,sub} methods had met the same fate: They are now called checked_{add,sub}_signed and overflowing_{add,sub}_signed , respectively. The older names are reserved for the transition.

Rustc-serialize support is now exactly identical to the counterpart for Serde. Previously two implementations didn’t agree to each other primarily because they are written by different contributors. Now they standardize on the std::fmt::Debug output, previously used by Serde implementations. This will cause the format change if you are using rustc-serialize to read and write a long lasting format, so you should be prepared for it. Rustc-serialize implementations actually covered more types than Serde in the past. They are now removed—more specifically, Date<Tz> and all offset types ( DateTime<Tz> support is rewritten per each Tz ). While it is not very trivial to reintroduce them in a sane manner, this removal should be considered temporary.

Near Future

This release contains lots of other minor breaking changes to allow more changes without breaking the compatibility. (Many fixes were blocked by them, for instance.)

The most significant one is that we no longer use Duration (that is, time::Duration ) for representing the time zone offset. It might sound strange but Offset is the “storage” offset type and Offset::local_minus_utc used to return the Duration for the offset “value”. Now the offset “value” is represented by FixedOffset (which is also a stroage type by its own), which has a good side effect that the offset is guaranteed to be within one day. In my experience this was a single biggest problem in implementing advanced time zone support—I expect this can be done much better by now.

We have also sorted out any types that were too public to be extended without breaking changes. For 0.3.0 they consist solely of formatting types, and they have received a private (dummy) field for the future expansion. We can now extend formatting (privately) without breaking public interfaces.

Far Future

There are two major concerns in the far future (I mean, next year or so) of Chrono.

First, Chrono will become a community project at last. I had initiated and maintained the project so far, but in the last year (2016) I had significant energy depletion that has prevented me to do anything that is not a daily job (as you may know, I also use Rust at work). Not that I think that the current version is good enough—I’ve resolved many required breaking changes I was aware of during the 0.3.0 release for example.

The Chronotope organization is, I think, the major step towards the community project, but that is not enough. I have reserved it in the past, but I invite you to #chronotope IRC channel at irc.mozilla.org. Also I’m willing to invite more contributors and relevant projects to the organization ( chrono-tz comes to my mind). I’m not sure how to start but having a venue for the discussion could be a good start.

Second, Chrono will set the official relationship to the standard library types. std::time::Duration support is the beginning, and what I’m most concerned is std::time::SystemTime .

In the past I thought that the time library will be kept as is and Chrono will fill the niche gap. The situation has changed— SystemTime no longer concerns about the calendar time. This means that the Chrono date and time types should be a canonical type for the calendar time while also filling the niche. This discrepancy was a source of design issues:

People seems to use DateTime<Tz> as a primary storage type, rather than as an alternative type used for formatting and calculation.

While it is designed to be much faster than alternatives, Chrono’s main representation still is a calendar time and causes overhead when you don’t need that. SystemTime::now() is at least 10x faster than UTC::now() .

The TimeZone type parameter is a source of many complaints. The original design was selected so that we don’t have to deal with the synchronization or sharing issue, and also we can get the needed information for date and time calculation, but my observation is that calculation is less used than formatting.