Proposal: strftime-based calendar/datetime formatting

[josevalim]

@kip

Although I started thinking this would be best done as configuration passed around in each structurally compatible Date , Time or DateTime struct or map, the variations are too many. I now feel it is better that this detail be backed into a module that implements the Calendar behaviour. This doesn’t make implementing a calendar any more complex. It does potentially have the side effect of having to generate calendar modules at runtime for some use cases.

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)?

@kip

Formatting for strftime should not be the calendars concern (in my opinion).

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.

@kip

Format encoding: %<flags><width><conversion> .

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.

@kip

Flags (based upon the Ruby implementation)

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.

@kip

I have included an options argument to strftime above because for localisation a locale name needs to be specified. In Python a locale is part of the stdlib and runtime environment but not so Elixir.

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.