I am all for this! However, I do have a note about the week-related stuff: On one hand, people might expect 'weeks' to be readily available (`:calendar` offers them, and many other libraries in other language environments do). On the other, many calendars do not themselves have a notion of weeks. (Weeks are only secondary units of date measurements (years, months, days are the primary ones) and nearly all calendars, all across the globe, use a seven-day week. Weeks are basically the months of the ISO week date calendar: https://en.wikipedia.org/wiki/ISO_week_date I wonder how much of the week-related functionality could be defined by just taking a date (in e.g. Calendar.ISO) and converting it into the ISO week date calendar.
~Qqwy/Wiebe-Marten On Monday, July 10, 2017 at 9:03:53 AM UTC+2, Kip wrote: > > With the new capabilities of Calendar in 1.5 I am now adding date and time > localisation to a package I maintain (https://hex.pm/packages/ex_cldr). > > CLDR (http://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns) > defines a number of symbols to aid formatting and localisation. Many of > these can be supported by the Calendar module (or easily derived). Some > would be better defined in a calendar module - which would imply adding > them to the behaviour and to Calendar.ISO. > > These functions are: > > 1. months_in_year(year) which together with the existing days_in_month/2 > would allow the calculation of quarters which is relevant in a lot of > business contexts > 2. week_of_year(date) which returns the week number within which the date > occurs. > 3. week_of_month(date) which returns the week of the month within which > the date occurs > 5. day_of_week_in_month(date) returns the ordinal day (i.e. 2nd in 2nd > Wednesday in July) > 6. year(date) which returns the effective year in which the date lies. > For example in an ISO Week implementation, the "year" may be different to > the "year in the date" > > Although my immediate focus is date formatting and localisation, these > functions are of themselves relevant for other "calendarists" (is that a > word?) Each of these may have quite specific implementation details > related to a given calendar and therefore would seem to be appropriate to > be part of the behaviour. > > I've tried to think of only those functions which cannot be readily > derived without knowledge of the specific calendar but I know this is a > slippery slope - especially with anything to do with time and dates. > > Thoughts? > > --Kip > > -- 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 on the web visit https://groups.google.com/d/msgid/elixir-lang-core/4c39d7cf-3bc2-4dc9-b11e-e2221139a080%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
