I am not sure I agree with this. 
The instants are the same and they are represented by the same year, month, day, hour, minute and second, so it does not feel to me they should be different calendars. To me, it is the same calendar, but it wants to be traversed or viewed in different ways. My suggestion would be to explore a WeekTraverser or WeekBuilder or some sort of behaviour that focuses on exploring a given calendar through different interpretations of its weeks. It may be even something that can be implemented on top of iso days (and therefore calendar agnostic)?
I agree with this but the calendar has to provide a default behaviour. So the recent proposal has a default week_of_year but you can customize it via the week_of_year option. The calendar also provides the default values for preferred time and so on and I don’t think we can escape this.
While I really like this idea, then we are no longer implementing strftime, so it needs to be a very conscious choice. The biggest benefit IMO is that it gets rid of all the padding options and, as you said, removes formatting concerns from the calendar.
Those flags are all officially supported by strftime but I decided to go only with three related to padding for now for simplicity. We can always add more later.
Isn’t this then forcing localization and therefore formatting concern into the calendar? I would prefer if the calendar does not receive a locale, ever. With the latest proposal, you can localize everything like this:
Calendar.format(datetime, "%format", MyApp.Calendar.format_config(:pt_br))
So I believe we are going with the loose contract you mentioned.
@kip assuming that we will merge the flags and width syntax that you proposed, are there any other changes you would like to see based on my reply?
Thank you.
