> My only intent was to define a standard Elixir API where, for any given date in any complying calendar, I could know upon which day of the week that day falls.
So I can think of two options: 1. You can use the atom :monday, as that should return the same meaning on all calendars based on our weekdays? In the same way that passing :sunday to Calendar.ISO makes it return the same value as "Calendar.USA". The benefit of this option is that it is supported for quite some time. 2. We introduce a new option, called :iso8601, which returns the default for iso8601, which is therefore :monday. My preference is 1 but I am open to hearing it is a bad idea. :D *José Valimhttps://dashbit.co/ <https://dashbit.co/>* On Sat, Jan 11, 2025 at 11:37 AM Kip Cole <kipco...@gmail.com> wrote: > > Also, in your case, couldn't you support a custom starting_on value > called :iso_default or :monday, which will behave as you described? > > In everything I do I try very hard to have a consistent implementation of > the Calendar behaviour. I believe that in most cases a user or developer > shouldn’t have to think about what calendar is in use - it’s just the right > calendar producing the right results. So while I could implement a custom > `starting_on`, that then sets my calendars apart from the default calendar > and other peoples calendars. I really really really want to avoid that. > Calendaring is hard enough as it is without developers having to > differentiate between them in their code. > > > my concern with this PR is that it opens up the path for "duplicating" > several of the functions in the Date module > > I’m just a pragmatist and a bit gun shy to argue any point here. My only > intent was to define a standard Elixir API where, for any given date in any > complying calendar, I could know upon which day of the week that day falls. > > If I’m the only person who thinks that’s a reasonable expectation then > there is no need to consider the proposal further. > > > > On 11 Jan 2025, at 8:33 pm, José Valim <jose.va...@gmail.com> wrote: > > Hi Kip, my concern with this PR is that it opens up the path for > "duplicating" several of the functions in the Date module: > > Date.iso_beginning_of_month/1 > Date.iso_beginning_of_week/2 > Date.iso_day_of_era/1 > Date.iso_day_of_week/1 > Date.iso_day_of_year/1 > Date.iso_days_in_month/1 > Date.iso_end_of_month/1 > Date.iso_end_of_week/2 > Date.iso_months_in_year/1 > Date.iso_quarter_of_year/1 > Date.iso_year_of_era/1 > > Perhaps not all of the above but at least a few. > > Also, in your case, couldn't you support a custom starting_on value called > :iso_default or :monday, which will behave as you described? > > So your :default can adhere to your custom calendar semantics, and then > either :monday or :iso_default returns what the computation above would > provide. > > > *José Valimhttps://dashbit.co/ <https://dashbit.co/>* > > > On Sat, Jan 11, 2025 at 9:45 AM Kip <kipco...@gmail.com> wrote: > >> A recent discussion <https://github.com/elixir-lang/elixir/pull/14162> >> clarified >> that the return value from `Date.day_of_week/2` is an ordinal value. That >> is, when it returns "1" that means "first day of week". It specifically >> does not mean "1" is Monday. >> >> That means that it would be useful to have a function that does return >> the cardinal day of week - that is, a number where 1 == Monday and 7 == >> Sunday. >> >> The function would look something like: >> >> def iso_day_of_week(%{calendar: Calendar.ISO} = date) do >> day_of_week(date) >> end >> >> def iso_day_of_week(date) do >> date >> |> convert!(Calendar.ISO) >> |> day_of_week() >> end >> >> This implementation relies on the knowledge that when called with >> starting_on = :default (which is the default argument value) the returned >> value is indeed 1 == Monday, 7 == Sunday. >> >> If there is any consensus I'll submit a PR. >> >> >> >> -- >> 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/eeff3e35-448b-4dcf-ad4a-866bac76a819n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/eeff3e35-448b-4dcf-ad4a-866bac76a819n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > -- > 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/CAGnRm4K1Avrg-Ro_%3DWdNTtwOM9CV-oWPPbn2rprG%2B5en9XPwOA%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K1Avrg-Ro_%3DWdNTtwOM9CV-oWPPbn2rprG%2B5en9XPwOA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > 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/B942BE1E-5FC3-4A0E-AE31-19267B436AD1%40gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/B942BE1E-5FC3-4A0E-AE31-19267B436AD1%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGnRm4KREP%3D75b6OuKqGheXTDXPke_hou6rdEfw-2bVxGa7fOg%40mail.gmail.com.
