For what it is worth, I'd prefer the solution proposed by Alexander to effectively make the boost::chrono types aliases for the equivalent std::chrono types and let boost::chrono provide additional functionality on top of those (such as I/O support, and additional clocks). At the end of the day, it means less code to maintain, document, test and distribute and the least amount of interoperability problems. Above all else, types like duration and time_point are interface types. If one library gives me a duration and I want to pass that to another library, I don't want to have to worry about converting types or worst of all mixing up scales (micro vs milli). **Solving this interoperability problem is exactly what standards are for!** Hence it should be left to the standard library to provide them wherever possible. So whatever else your opinion on the proper scope of the standard library and the committee's responsibility is, please don't try to overshoot your target. In particular not where already existing types are concerned. On a practical note: As such a change would be breaking in more than one way (c++11, ADL-effects and multiple function overloads that now resolve to the same signature come to mind), this should be announced 1-2 releases in advance -- which of course requires that someone with the necessary authority actually makes a decision. An intermediate step might be to e.g. let boost duration inherit from std duration and add a implicit conversion constructor. That way ADL should continue to work as expected and previously distinct types would remain distinct types. However it would still require c++11 and there might be more subtle ways in which this breaks existing code. Best Mike