I am OK with delegating more functions to calendar as long as we have use cases for it. I am also OK with adding a year function but we need to come up with a better name. :)
Thanks for looking into this Kip! *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Mon, Jul 10, 2017 at 9:03 AM, Kip <[email protected]> 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 [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/20060086-74b8-4a40-bbf4- > a160783f94d9%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/20060086-74b8-4a40-bbf4-a160783f94d9%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JFWUU4kfar53n5-jRofS4O8WJmZXfyNrQSp6i3kwuerA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
