Add DateTimeFormat

[zbraniecki]

This is a port of https://github.com/zbraniecki/unic-datetime for ICU4X.

The intention of this PR is to get to the point where we have the first formatter API MVP ready to land.

The MVP should contain:

• DateTimeFormat constructor and format
• FormattedDateTime
• Ability to write to Write and to String
• DateStyle/TimeStyle options bag

The integration into DataProvider is intended to be handled in a separate PR.

[coveralls]

Pull Request Test Coverage Report for Build 3d4652bf545094010d3df4c1b6835c08ed7e9e0b-PR-202

• 403 of 569 (70.83%) changed or added relevant lines in 13 files are covered.
• 27 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+28.2%) to 77.778%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
components/datetime/src/pattern/mod.rs	52	54	96.3%
components/datetime/src/fields/length.rs	7	12	58.33%
components/datetime/src/options/mod.rs	7	12	58.33%
components/datetime/src/options/style.rs	6	12	50.0%
components/datetime/src/pattern/error.rs	0	6	0.0%
components/datetime/src/options/preferences.rs	0	10	0.0%
components/datetime/src/error.rs	0	13	0.0%
components/datetime/src/options/components.rs	13	28	46.43%
components/datetime/src/fields/symbols.rs	71	96	73.96%
components/datetime/src/provider.rs	87	120	72.5%

Files with Coverage Reduction	New Missed Lines	%
components/data-provider/src/data_entry.rs	3	88.0%
components/num-util/src/fixed_decimal.rs	24	94.53%

Totals
Change from base Build f49fdbece75590675fb1c70057c7257251e2fd2e:	28.2%
Covered Lines:	3024
Relevant Lines:	3888

---

💛 - Coveralls

[zbraniecki]

I applied a generic feedback I collected on the WIP over the last week - in particular, I took Shane's comment about "maybe a string of skeleton/pattern is not the fastest way" and run away with it.

I now have fields that Skeleton and Pattern can use (I don't have a Pattern yet, but basically an iterator over PatternItem), and we can output (and in the future parse) the skeleton from/to string, and I hope to be able to do the same with Pattern, but internally, we can operate on structures and also see if we can find a way to store skeletons/patterns in space-efficient and performant way.

Two things I'd like to have a vision for next are:

• Some form of skeleton->pattern matching
• Understanding of how FormattedDateTime should look like and how formatToParts on it should work.

@mihnita and @sffc - can I get your help with this?
Also, a generic skim over the current code would be appreciated :)

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• Cargo.toml is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[zbraniecki]

@sffc @mihnita - I'd love to get your initial review soon. I don't think this is ready for landing, and I want to work on code cleanups, documentation, coverage and tests, but the core should be ready for initial landing according to what we discussed last week.

[sffc]

Thank you for applying my suggestions!

We'll need to think more about the form of the Year/Month/Day types when we introduce non-Gregorian calendar systems in a future PR that hopefully lands soon after this one.

[mihnita]

Nit: I think you added millisecond at some point, but now it's gone?

[zbraniecki]

Yes, sorry for not explanining. I initially prototyped a larger version of this api to understand the facets that included most of ldml, skeletons, components etc. Then, in result of our agreement to trim it to minimum I removed almost all pieces that weren't strictly needed and yet the review took over 150 comments. Shane called out a number of places where I bits and pieces were left that aren't needed for this PR and I went through a cleanse to remove them all. We don't use milliseconds in styles so I removed it and will bring back when we work on skeletons.
Is that ok with you?

[sffc]

(setting review bit)