Add a ZonedTime type

[sffc]

It can live next to ZonedDateTime.

Why: in order to use TimeFormatter to format a time and a zone together.

Other solutions considered but infeasible:

1. Use ZonedDateTime: no, it has a calendar, but TimeFormatter has the () calendar
2. Implement InFixedCalendar<()> for ZonedDateTime: no, this breaks type inference for everyone else
3. Add format_any_calendar to TimeFormatter: possible, but seems confusing; ZonedTime is better

@Manishearth @robertbastian

[Manishearth]

no, this breaks type inference for everyone else

Important to note, this breaks type inference in an intractable way. A property we currently have is that let dtf = FixedCalendarDateTimeFormatter::new(YMD); dtf.format(datetime) automatically infers the correct calendar. There's no way to make FCDTF<(), ..> not care about calendars without having the above code also be valid for the no-calendar time case.

In general I consider passing e.g. a DateTime to a TimeFormatter to be a bit of an antipattern, it's nice that we support it and there are likely ways it will be convenient, but I don't want to encourage that. ZonedTime seems like a good way to avoid such constructs.

[robertbastian]

Why: in order to use TimeFormatter to format a time and a zone together.

Not to throw a wrench in the works, but I'm not convinced of this use case. A non-local time should always be accompanied by a date, because often it is on a different day. I believe it makes sense to require a date whenever a time zone is involved.

[sffc]

I mostly agree with you @robertbastian, but this opinion does not seem to be widely held, and people want to represent and display things like "10:00 PST".

For example, the ICU4X WG meeting is typically at 10:10 uslax on Thursdays. It is a zoned time, not specific to a date.

[Manishearth]

A non-local time should always be accompanied by a date, because often it is on a different day

Things can be "daily at 10 Pacific". This is definitely something I've seen formatted relatively often in online spaces.

I think this is still a valid use case.