With Calendar.strftime/2 being merged into Elixir master (from the NimbleStrftime lib) I’d like to open a proposal on some additional formatting options and gain community feedback.
There are three sub-proposals and any and all feedback is welcome.
Weeks (yes, again with the weeks conversation 
)
Linux strftime has formatting flags for weeks. These being:
%U The week number of the current year as a decimal number, range
00 to 53, starting with the first Sunday as the first day of
week 01. See also %V and %W. (Calculated from tm_yday and
tm_wday.)
%V The ISO 8601 week number (see NOTES) of the current year as a
decimal number, range 01 to 53, where week 1 is the first week
that has at least 4 days in the new year. See also %U and %W.
(Calculated from tm_year, tm_yday, and tm_wday.) (SU)
%W The week number of the current year as a decimal number, range
00 to 53, starting with the first Monday as the first day of
week 01. (Calculated from tm_yday and tm_wday.)
Adding this formatting directives would require an update to the Calendar behaviour to provide support.
Options:
- No need, don’t add
- Just add
%V for the ISO week number and add Calendar.iso_week_of_year/1 to the Calendar behaviour
- Maximise compatibility, go with all three and add the callbacks
Add support for Era
Calendar.day_of_era/1 returns {day, era} but that’s an integer, not a display format. Calendar behaviour doesn’t do any display format translation today. The new Calendar.strftime/2 does display format translation for AM and PM (and variants). So one approach is to simply enhance Calendar.strftime/2 to also map Calendar.ISO eras 0 -> display_name and 1 -> display_name. And there would need to be agreement on display name (AD versus CE and BC versus BCE).
Era isn’t used in day-to-day formatting for Gregorian calendars except for dates before year 1. It is used as a standard part of formatting Japanese calendars and for some format of Chinese calendars (and derivatives on the 60 year cycle).
strftime defines the following directives:
| Specifier |
Meaning |
| %Ec |
Date/time for current era. |
| %EC |
Era name. |
| %Ex |
Date for current era. |
| %EX |
Time for current era. |
| %Ey |
Era year. This is the offset from the base year. |
| %EY |
Year for current era. |
These can be implemented without a change to the calendar behaviour if Calendar.strftime/2 treats era like it treats am/pm and provides an internal translation. It would perhaps be better that both of these (ie am/pm and era translations became behaviours since that would also help in international projects using Gettext or Cldr.
Options
- Era? Who cares, forget about it
- Compatibility is a good idea and implementation seems simple. Do it.
- I care about calendars beyond
Calendar.ISO so I need this (I’m not holding my breath on this one )
Localised number systems (ie not Latin alphabet)
strftime supports localising the date format to use non-latin alphabets. These is also supported in ex_cldr and friends. The default for these directives is to use the Latin alphabet so implementing these directives is quite trivial. If no configuration is provided in options, use the fallback to the Latin characters.
The formatting directives are:
| Specifier |
Meaning |
| %Od |
Represents the day of the month, using the locale’s alternative numeric symbols, filled as needed with leading 0’s if an alternative symbol for 0 exists. If an alternative symbol for 0 does not exist, the %Od modified conversion specifier uses leading space characters. |
| %Oe |
Represents the day of the month, using the locale’s alternative numeric symbols, filled as needed with leading 0’s if an alternative symbol for 0 exists. If an alternative symbol for 0 does not exist, the %Oe modified conversion specifier uses leading space characters. |
| %OH |
Represents the hour in 24-hour clock time, using the locale’s alternative numeric symbols. |
| %OI |
Represents the hour in 12-hour clock time, using the locale’s alternative numeric symbols. |
| %Om |
Represents the month, using the locale’s alternative numeric symbols. |
| %OM |
Represents the minutes, using the locale’s alternative numeric symbols. |
| %OS |
Represents the seconds, using the locale’s alternative numeric symbols. |
| %Ou |
Represents the weekday as a number using the locale’s alternative numeric symbols. |
| %OU |
Represents the week number of the year, using the locale’s alternative numeric symbols. Sunday is considered the first day of the week. Use the rules corresponding to the %U conversion specifier. |
| %OV |
Represents the week number of the year (Monday as the first day of the week, rules corresponding to %V) using the locale’s alternative numeric symbols. |
| %Ow |
Represents the number of the weekday (with Sunday equal to 0), using the locale’s alternative numeric symbols. |
| %OW |
Represents the week number of the year using the locale’s alternative numeric symbols. Monday is considered the first day of the week. Use the rules corresponding to the %W conversion specifier. |
| %Oy |
Represents the year (offset from %C) using the locale’s alternative numeric symbols. |
Options
- Who cares about countries and people that don’t use the Latin alphabet. Forget it.
- Good idea - easy to implement, no impact if I’m not doing non-latin alphabet code. Glad to see Elixir embracing global cultures (ok, I’m pitching I know )
