Use dateSkeletons/timeSkeletons for DateTimeFormat Lengths

[zbraniecki]

CLDR 40 introduces dateSkeletons and timeSkeletons - https://cldr.unicode.org/index/downloads/cldr-40

The end goal is to allow implementations to work solely with skeletons instead of patterns.

If I'm not mistaken that means that our length bag selection would, instead of taking datePatterns and timePatterns would take date skeleton or time skeleton, select the best pattern for it (can we assume there's always a perfect match in skeleton-patterns map?).

I'm not sure how urgent it is and whether datePatterns/timePatterns is planned to be deprecated or what the value proposition here is for us (seems like more computing and we need to pull in more data).

Alternatively, we could do it in the build step and pull CLDR data for skeletons and lengths, and store ICU4X data still with resolved patterns like we do for now, which seems optimal for small chunks of data in length bag scenario, but I assume there must be a reason CLDR is moving away from it.

[sffc]

I see the new CLDR data for dateSkeletons and timeSkeletons to be a stepping stone toward the data we ultimately need in order to implement the new datetime APIs (#272 / #645), the ones Greg presented in the deep dive a few weeks ago.

[zbraniecki]

Do we expect those to live in parallel forever in CLDR or do you expect the skeletons to replace patterns?

Asking because I'm thinking about it more and getting more convinced that unless there's some quality of output reason, for length bag we should continue storing ICU4X data lengths as patterns (so that we don't need to pull skeleton-pattern maps for that scenario).

[sffc]

The idea is that if you apply the UTS 35 skeleton mapping algorithm on a given CLDR release, the skeletons should produce the exact same patterns.

If CLDR ever decided to remove the explicit patterns data (which they may or may not do), ICU4X could still decide to re-generate the patterns at build time and store them in the data file in order to reduce data size or improve performance.

[zbraniecki]

ICU4X could still decide to re-generate the patterns at build time and store them in the data file in order to reduce data size or improve performance.

Great! I think we can close it for now then with this as recorded recommendation of action from me.