In ICU4X 0.1 we introduce a DateTimeFormat API for formatting date and time into human readable formats. That API is shaped after ICU4C, ICU4J and ECMA-402.
In order to clearly separate the concerns, we are leaving a challenging task of designing a complete solution for date and time management to the Rust community, and we can only formulate the request for what API ICU4X will need to format such structure.
We have prepared a design doc discussing the data we need in ICU4X DateTimeFormat in order to produce properly localized strings.
We want to help the community understand the intended separation of concerns -- date and time management, including date and time arithmetic, should not be overlapped with formatting of the data.
Both tasks are very challenging and the history of Software Industry is filled with half-finished or badly designed APIs that attempted to "start small" and "scale" - a model which unfortunately doesn't work well for either of the two tasks.
We believe ICU4X DateTimeFormat will handle the formatting portion correctly with ergonomics, performance and quality backed by Unicode and CLDR projects.
In ICU4X, we also intend to implement a low-level, performance-focused API for calendrical calculations, enabling the conversion of dates between calendar systems. However, we do not intend to design a high-level API for this step; we intend to leave the ergonomic datetime arithmetic API to the community.
There are surprisingly few examples of good date and time APIs in the industry that we feel confident to recommend. We strongly believe that the history of JavaScript Date, C++ std::chrono or Java LocalDateTime and a long history of shortcomings and limitations of them, particularly in relation to i18n, serve as a cautionary tale for anyone aiming to design a reference one for Rust.
In particular, we believe that correct date and time management API must include calendar and time zone.
It is our experience that such functionality is incredibly hard to retrofit into an existing API. Therefore it is our belief that such functionality must be planned very early in the API design.
We do not see any crate in the current ecosystem that covers those two features.
One example of an API that is being meticulously designed to handle the scope correctly is EcmaScript Temporal Proposal. We encourage everyone interested in the topic to read through the Design Doc for it.
It is our hope that we can collaborate together to provide a complete date and time solution for management and formatting together.