Should NeoFormatter and TypedNeoFormatter have default generics?

[sffc]

Currently if you want a time formatter you need to explicitly set the calendar type to NeverCalendar / ().

This raises the general question, should they have default generics?

The time formatter specific concern can also be addressed by

1. Make a type alias such as pub type TimeFormatter
2. Make format_time imply this bound

@Manishearth @robertbastian

[Manishearth]

I don't really think there's a sensible "default" here. I think TimeFormatter is fine. I also think adding the bound may work, though it would be nice if DateTimeFormatter could format_time too.

[sffc]

This currently works:

TypedFormatter::try_new(
  locale,
  fieldset::YMD::with_length(Medium)
)
.format(Date::try_new_gregorian_date(...))

This currently requires an explicit NeverCalendar:

TypedFormatter::<NeverCalendar, _>::try_new(
  locale,
  fieldset::HM::with_length(Medium)
)
.format(Time::try_new(...))

If we had format_time (#5269 (comment)), the type inference should work because the function would be defined on Formatter<NeverCalendar>

TypedFormatter::try_new(
  locale,
  fieldset::HM::with_length(Medium)
)
.format_time(Time::try_new(...))

[sffc]

What would pub type TimeFormatter map to?

pub type TimeFormatter<FSet> = TypedFormatter<NeverCalendar, FSet>
pub type TimeFormatter<FSet> = Formatter<FSet>
pub type TimeFormatter = TypedFormatter<NeverCalendar, TimeSkeleton>

[sffc]

I don't consider this a 2.0-beta blocker.

[sffc]

Shane/Rob discussion:

@sffc Note: I have already replaced NeverCalendar with (). We currently have:

DateTimeFormatter<_>  // field set
FixedCalendarDateTimeFormatter<(), _>  // calendar, field set

Discussion:

• @robertbastian - We could add a type alias for TimeFormatter<FS> = FixedCalendarDateTimeFormatter<(), FS> so that the weirdness is a bit more hidden
• @sffc It applies to time and time zone.

Bikeshed:

1. TimeFormatter
2. NoDateFormatter
3. NoCalendarFormatter
4. DatelessFormatter
5. TimeFormatter + TimeZoneFormatter

Discussion:

• @robertbastian I think 5 is best, it adds a small amount of API but it's the names people will be looking for. You don't want to think about calendars at all if you try to format a time
• @sffc It's confusing that TimeZoneFormatter can format other things besides time zones. I'm okay with TimeFormatter to start. It's not that weird to say to use TimeFormatter to format a time zone.
• @sffc Observation: you would be able to construct a TimeFormatter<fieldset::YMD>, but there is no type that satisfies the bounds for the .format function.

Conclusion:

• Add a TimeFormatter type alias
• Do not add default generics

LGTM: @sffc @robertbastian

[sffc]

TimeFormatter has been added.

[robertbastian]

• @robertbastian We have a uncalendared formatter and a calendared formatter. These are currently called TimeFormatter and DateTimeFormatter. You should use TimeFormatter to format time zones (not the main DateTimeFormatter type), and you can use DateTimeFormatter to format ZonedDateTimes, not just DateTimes, Dates, and Times (in fact you shouldn't use DateTimeFormatter to format Time). Both of these are confusing
• @sffc The main difference is that Date "always" needs the calendar info, whereas Time and TimeZone "never" need it.

Calendared input types:

• Date
• DateTime
• ZonedDateTime

Uncalendared input types:

• Time
• UtcOffset
• TimeZone

Discussion:

• @robertbastian - CalendaredFormatter (+ FixedCalendarCalendaredFormatter), UncalendaredFormatter
• @Manishearth DateTimeFormatter, FixedCalendarDateTimeFormatter, UncalendaredDateTimeFormatter
• @sffc CalendarFormatter, FixedCalendarFormatter, TimeOrZoneFormatter
• @robertbastian CalendaredFormatter, FixedCalendaredFormatter, SimpleFormatter
• @Manishearth There are 3 tiers: all calendars, single calendar, or no calendar
• @sffc CalendarFormatter, FixedCalendarFormatter, NoCalendarFormatter
• @sffc WithDateFormatter, WithoutDateFormatter
• @robertbastian DateTimeFormatter is named like that because it is the formatter in the datetime crate. If someone said "to format time zones, use NoCalendarFormatter", that makes more sense to me than TimeFormatter.
• @Manishearth and I think that type of confusion is more likely when you have FooFormatter and BarFormatter where Foo and Bar are not exhaustively listing what they format, you just have to guess "well DateTimeF formats zones but does TimeF format zones??????". This is less confusing if they are all called SomethingFooFormatter.
• @robertbastian Should it be NoCalendarDateTimeFormatter?
• @sffc No because (1) it doesn't format dates, (2) there is no such thing as a NoCalendarDateTime because all datetimes have calendars, and (3) this is a type people should use so it should not have a long scary name
• @Manishearth I think the confusion of thinking different formatters format certain types is more likely when the different formatters don't share the same suffix
• @sffc Should it be named DateFormatter because you use it for formatting dates.
• @robertbastian It is called DateTimeFormatter in so many other contexts.

Conclusion:

1. DateTimeFormatter and FixedCalendarDateTimeFormatter remain as-is
2. Rename TimeFormatter to NoCalendarFormatter

LGTM: @Manishearth @robertbastian @sffc