Add datetime API for loading length patterns, sitting on top of semantic skeleta

[sffc]

trafficstars

CLDR issue: https://unicode-org.atlassian.net/browse/CLDR-17775

Semantic skeleta allow a lot of flexibility for locales to select the fields most relevant for their formatting.

However, they produce different output than date length patterns since the backing CLDR data is different.

For 2.0, I suggest moving forward with something like this:

use icu::datetime::{YearMonthDay, CldrDateStyle, Length};

// Semantic Skeleta data
icu::datetime::Formatter::<YearMonthDay>::try_new(locale.into(), Length::Short)

// CLDR Length Pattern data
icu::datetime::Formatter::<CldrDateStyle>::try_new(locale.into(), Length::Short)

This way, in 2.0, we nudge users toward semantic skeleta, but we give an escape hatch for using the CLDR date length data, which is well signaled.

Thoughts? @eggrobin @zbraniecki

[sffc]

What I want to do for 2.0:

• Keep both YearMonthDay and Auto styles
• Rename Auto to CldrLength or similar; possibly keep it behind an experimental feature? Delete it if/when CLDR decides to properly consolidate it.

[sffc]

The LDML spec doesn't include CldrStyle so I would like to remove it.

@zbraniecki to post more info / screenshots.

[zbraniecki]

This is what's in Windows 10:

• https://bug1308329.bmoattachments.org/attachment.cgi?id=8801351
• https://bug1308329.bmoattachments.org/attachment.cgi?id=8801352

This is MacOS:

• https://bug1308329.bmoattachments.org/attachment.cgi?id=8801353
• https://bug1308329.bmoattachments.org/attachment.cgi?id=8801354

(based on https://github.com/tc39/ecma402/issues/109 )

I think the trend is to simplify it, as I don't have access to latest Windows, but on latest MacOS I can't find the same UI in my Settings.

[sffc]

OK, got it, this is just about the OS override stuff?

I think the right design is to implement this in a thin wrapper that sits on top of icu::datetime::Formatter. I'd be fine having that be in the crate as a first-class supported abstraction.

I'm going to repurpose this issue and remove it from the 2.0 milestone.

[sffc]

Discussed with @zbraniecki. It is solvable via either the higher-level type in ICU4X or in userland, so this doesn't need to block 2.0.

[sffc]

WG notes:

• @nekevss How do we map style, and how do we map component fields?
• @sffc
  • Date length: Full is Long with YMDE; Long/Medium/Short are that length with YMD.
  • Time length: Full is TZ with specific long and second precision; Long is TZ with specific short and second precision; Medium is T with second precision; Short is T with minute precision.
  • Components:
    • Length: The month length determines the semantic skeleton length; everything else determines field set presence only.
    • Alignment: If any field is 2-digit, then set the column alignment.
    • Missing/partial date fields (e.g. year and day): Pick the narrowest semantic skeleton that covers all of the fields that are specified in the components bag.
    • Missing/partial time fields: pick a time precision based on the least-significant field that is specified.
• @sffc This means not every valid ECMA option combination is representable right now. I want to start with this lossy mapping and add back in the things that matter once we can understand the impact better.
• @sffc I would find it very useful for Boa to implement it this way, and then we can measure the impact on web sites if DateTimeFormat uses this more restricted algorithm versus the more general currently implemented in V8/SpiderMonkey.