Maybe this can inspire your team since it has some bigger and interesting design deviations from Joda-Time and JSR-310 or other libraries. I don't know how much OO-principles are useable in Rust language, but surely Rust library could take advantage from timeline concept, duration handling and element-centric approach in Time4J (to mention three outstanding highlights).

https://github.com/menodata/time4j

Else good luck with your project, it is a very huge work you are going to start (I know it from my own experience).

Is there anything I can do to contribute to datetime-rs? Looking to get my feet wet with Rust.

Just wanted to note that your background and design notes are well written and fairly comprehensive. I had a few minor points I wanted to make.

1. JSR-310 ended up going to considerable trouble to define a way around leap seconds. You've obviously found the details. Perhaps you could consider matching or referencing the "Java time-scale"? The definition was very carefully worded and it would be good to see other libraries build on its distinctive side-stepping of leap-seconds and ability to adapt to future changes/abolition.

2. In conceptual data types, I'd note that JSR-310 uses Period for date-based and Duration for time-based. Removing hours/minutes/seconds from Period greatly simplified the API, and you may find the same.

3. I personally think that choosing 100ns ticks is unfortunate although I fully understand the rationale. I've seen various complaints over the years about data read from databases (at 1 ns "precision") being lost when it is round-tripped via an application. This resulted in a 1ns precision in JSR-310 being a very hard requirement. It also matches much better increases in performance and accuracy that we should expect over the next 20 years. JSR-310 uses i64 seconds and i32 nano-of-second which was relatively easy to deal with mathematically (although I wish Java had a 96 bit or 128 bit primitive type). As a side note, if you do this, then a 1970 epoch makes a lot of sense as the epoch-second value matches classic Unix/Java.

4. It looks like you won't handle other calendar systems. This will simplify your API greatly, which JSR-310 could not do.

In summary, JSR-310 is a product of the Java programming language which does yield some additional complexity. The fields/units allow multiple calendar systems and formatting to work but add complexity, particularly the need to have an interface layer (the temporal interfaces exist for interoperation, not for user code).

As I believe you have identified, the key to a successful API is to represent the concepts of date and time in a compatible manner between languages. The details of methods, formatting, parsing and so on are very much where a specific language makes itself felt (although it would be good to try and match the algorithms for plus/minus in LocalDate and ZonedDateTime to aid developers porting code between languages).

Good luck!