You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
()
calendarInFixedCalendar<()> for ZonedDateTime
: no, this breaks type inference for everyone elseformat_any_calendar
to TimeFormatter: possible, but seems confusing; ZonedTime is better@Manishearth @robertbastian
The text was updated successfully, but these errors were encountered: