Shane F. Carr

UTS 35 says: > The numberSystem attribute is used to specify that the given number formatting pattern(s) are to be used when the given numbering system is active. By default,...

My initial reaction is that I think this is a beneficial change. Returning things from closures is a pain, especially closures with restrictive lifetime parameters like the ones here. Does...

I think `R: 'static` solves a lot of use cases; it allows the closure to return primitives and owned data, which it can't currently do since the closure is required...

In addition to hour cycle and era display, I also need an option for fractional second digits, unless that gets modeled as part of the field set.

Would like comments from @robertbastian and @zbraniecki

Discussion on constructors, also with implications on NeoOptions: ```rust use icu::datetime::fieldsets::YMD; use icu::datetime::DateComponents; icu::datetime::Formatter::::try_new(locale, options) icu::datetime::Formatter::try_new_with_components(locale, DateComponents::YearMonth, options) // Zibi prefers: icu::datetime::Formatter::try_new(locale, YMD, options) // Shane: It can also be...

I want to explore the field set being the options type. We would get call sites like this: ```rust icu::datetime::Formatter::try_new(locale, YMD::with_length(Length::Medium)) ``` The function signature is ```rust impl Formatter {...

We haven't reached consensus on the input types. Currently, we have: ```rust impl TypedNeoFormatter where R::D: DateInputMarkers, R::T: TimeMarkers, R::Z: ZoneMarkers, { pub fn format(&self, input: &I) -> FormattedNeoDateTime where...

I discussed this a bit with @robertbastian and @Manishearth today. I didn't take notes, but here were some of my takeaways: Creating `struct Input` makes the bounds on `Formatter` a...

> ICU4X Dates are not 100% cheap to construct, so I'm worried about other datetime libraries paying that cost. `DateTime` is quite cheap to construct, and most third-party crates would...