DateTimeNames: Support loading of AnyCalendar names

[sffc]

Currently we only support names-loading in TypedDateTimeNames (which should be renamed to FixedCalendarDateTimeNames). We could also add the AnyCalendar variant of this.

For example, we could add DateTimeNames::load_month_names.

If you need this feature, please reply here to explain your use case.

[Nerixyz]

I'm not sure if this is the right issue. My use case is a binding for a scripting language, where I want to add the possibility to specify patterns. For the "regular" formatting, I take a date specification, a locale, and a FieldSetBuilder. Ideally, I could create a similar function that takes a pattern string instead of the builder. DateTimeNames::new_without_number_formatting seems like the closest one, but it requires a calendar where I don't know which one I should use.

---

A bit related to this: It would be great if one could check which parts of a zoned datetime are actually required for a pattern. Because CompositeFieldSet requires a fully specified zoned datetime, I'm default initializing missing fields, but checking that these aren't used when formatting. With CompositeFieldSet this is fairly easy, as one can match on it and find the required parts. FixedCalendarDateTimeNames::include_for_pattern can "get" that information, but it's not accessible to users.

[sffc]

For now, FieldSetBuilder supports Serde, so you can use JSON as the string form.

I'm working with CLDR to refine the official string representation, which we hope to leverage in MF2. See e.g. unicode-org/message-format-wg#1067

[sffc]

Also, forgot to mention this, but thank you for the feedback on 2.0 Beta! This is really helpful to make sure 2.0 serves the needs of clients.

A bit related to this: It would be great if one could check which parts of a zoned datetime are actually required for a pattern. Because CompositeFieldSet requires a fully specified zoned datetime, I'm default initializing missing fields, but checking that these aren't used when formatting. With CompositeFieldSet this is fairly easy, as one can match on it and find the required parts. FixedCalendarDateTimeNames::include_for_pattern can "get" that information, but it's not accessible to users.

So, the way this is designed, the TimeZoneInfo only needs the fields that are required by the time zone style being formatted, assuming that you are using static field sets.

If you are using CompositeFieldSet, it assumes the worst and requires all four pieces of the TimeZoneInfo. But also, if you are doing runtime field selection, you might need everything. You can usually build a TimeZoneInfo without needing to supply fake ("default initialized") data.

If you know for sure that you are only ever displaying a TimeZone with an offset, but you want runtime selection of the date fields, you can use Combo<DateFields, zone::LocalizedOffsetShort>, for example. We don't currently have an abstraction for something like this but with time zone being "optional".

On the main branch, new since 2.0-beta2, I added a format_unchecked function that does runtime checking instead of compile-time checking of fields and calendars. Does this function work for your use case?

[Nerixyz]

Sorry for the late response.

On the main branch, new since 2.0-beta2, I added a format_unchecked function that does runtime checking instead of compile-time checking of fields and calendars. Does this function work for your use case?

Thank you, this does fit my needs for the DateTimeFormatter. For a DateTimePattern it's not really possible to check what it requires.

---

For the date time pattern formatting, I should've made my question a bit clearer (and I don't know if that's the right way to use the API).
Ideally, I'd want something like this:

fn format_ideal(pattern_str: &str, locale: &str, zdt: &ZonedDateTime<Iso, TimeZoneInfo<Full>>) {
    let prefs = Locale::from_str(locale).unwrap().into(); // potentially includes -u-ca-
    let pattern = DateTimePattern::try_from_pattern_str(pattern_str).unwrap();
    let mut names = AnyCalendarDateTimeNames::try_new(prefs).unwrap();
    let _ = names.include_for_pattern(&pattern).unwrap().format(zdt);
    // ...
}

Not sure if this would require a new -Names type, but my idea was that AnyCalendarDateTimeNames would resolve the calendar(-kind) like DateTimeFormatter::try_new (I suppose through FormattableAnyCalendarKind::from_preferences). Otherwise, it would work like FixedCalendarDateTimeNames.

[sffc]

Yeah, that use case would be served with adding functions onto DateTimeNames. You found the right issue for that.

Always worth verifying, though: are you sure you want DateTimeNames? Where do you get your patterns from?

[Nerixyz]

are you sure you want DateTimeNames? Where do you get your patterns from?

The patterns are from users who (should) know the formatting rules for the specific locale.
I'm exploring alternative designs for Typst's datetime to support locale specific formatting (it only supports US English right now). I have an API that uses the fieldsets with serde, but I wanted to see if I could provide a pattern-like API as well.