Hmm, I suppose the flaw in my argument is that the optional argument functions aren't really callbacks, and they are part of the public API. Which means this is a breaking change for anyone using a function value for an option.
On Thursday, January 30, 2025 at 12:52:42 PM UTC+11 Kip wrote: > *Proposal summary* > > Change the callback function signature for `Calendar.strftime/3` options > to pass both a number and the first arguments calendar. > > *Explanation* > > Today `Calendar.strftime/3` allows a function to be provided as an option > to any of the keywords. This is very helpful when working with localised > calendars because a simple function call can return all the data relevant > to the localised date. For example: > > iex> Calendar.strftime ~D[2020-01-30 Cldr.Calendar.US], "%a", > MyApp.Cldr.Calendar.strftime_options!() > “Fri" > > But there’s an issue: That date is actually a Thursday, not Friday! So > what’s going on? Internally `Calendar.strftime/3` is calling > `Date.day_of_week/1`. That function returns a number representing the nth > day of the calendar-relative week (so-called ordinal day). There is the > same issue with month of year because not all calendars start in January. > For example, the Australia tax year calendar starts in July. > > Since the US official calendar starts its weeks on Sunday - unlike > Calendar.ISO which starts its weeks on Monday (like many territories) - the > day name lookup failed to show the correct result. This is because the > callback didn’t have the calendar context to know what the default > start-of-week day is. > > Now that can be worked around by specifying the calendar in > MyApp.Cldr.Calendar.strftime_options!/1 > like this: > > iex> Calendar.strftime ~D[2020-01-30 Cldr.Calendar.US], "%a", > MyApp.Cldr.Calendar.strftime_options!(calendar: Cldr.Calendar.US) > “Thu" > > But that feels an error prone. Perhaps it would be better to pass the > calendar of the date/datetime/time argument to the callback functions > instead? Today those functions receive a number only. This proposal is to > have the functions receive both a number and the calendar of the first > argument (which might be nil). This would give appropriate context to the 4 > out of the 5 callback functions that would benefit from it (2 each for > month name and day names). > > *Precedent* > > This would be a breaking change for the callback signature - but not for > the Calendar.strftime/3 public function. There is some limited precendent. > For example when the `Calendar.day_of_week/3` callback changed to be > `Calendar.day_of_week/4`. That change affected the implementation of > alternative calendars, but it did not affect consumers of those calendars. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/583251f8-b182-4133-8a9d-03bc3b96ae74n%40googlegroups.com.
