Pardon for a somewhat offtopic post and a shameless plug: as a joke for April 1st I've created an implementation of International Fixed Calendar: https://github.com/wojtekmach/calendar_ifc and I've recently updated it to use new calendar types - it might be of some interest to the people in this thread.
2016-12-19 11:21 GMT+01:00 José Valim <[email protected]>: > > This is even a small ambiguity in an ISO calendar since the question of >> “first day of the year” depends on whether you mean the first day of the >> first week, or the first day of January. >> > > ISO8601 defines three representations: Calendar date, ordinal date and > week dates. We could explicitly document we are implementing the first > format. > > But if your calendar starts on “first thursday of april” then the last day >> can only really be encoded as {m, y} in the gregorian calendar because the >> notion of a month in this calendar does not align with a gregorian month >> boundary. I suppose that if the definition of `last_day_of_month` was >> changed to mean “number of days in a month” then this type of calendar >> could be implemented without change and still be compliant with the >> calendar behaviour. >> > > If you have a calendar where the first month starts on "first thursday of > April" and finishes the first month on the "first wednesday of May" such > calendar still has a notion of months. In a leap week calendar they would > all have 28 days with the exception of a month with a leap week (which > would have 35). > > Writing the paragraph above also made it absolutely clear that you are > indeed correct: days_in_month/2 is a better name than last_day_of_month/2. > Since last_day_of_month/2 was not yet released (only in RCs), I will go > ahead and rename it. > > On the other hand, You could also have week-based calendars that have no > notion of months and therefore last_day_of_month or days_in_month have no > purpose. Those probably wouldn't be representable with Elixir's calendar > types. > > >> But I would still need some way to define configuration. How do I >> capture that my version of Calendar.FiscalYear starts on July 1st, and >> another one starts on April 1st. All other rules are the same - just a >> different start date. >> > > Calendar modules are backends that power DateTime, Date, and > NaiveDateTime. This means you could have a function such as: > > FiscalYear.define(MyApp.AprilCalendar, starts_at: "foo", ends_at: "bar") > > > The above would define a module named MyApp.AprilCalendar that implements > all of the Calendar behaviour functions. It works similarly to the metadata > you have mentioned, except such parameters are defined at compilation time, > rather than runtime. > > However, it is still not clear if the above would be the preferred > solution to the problem. I am still partially inclined to think having a > FiscalYear module that works orthogonally to the ISO calendar would work > best. In such approach, you would have: > > FiscalYear.define(MyApp.AprilBased, starts_at: "foo", ends_at: "bar") > > > That would define a module mirroring many of the functions in > Date/DateTime except they do fiscal year related manipulations. For > example, you could have Date.beginning_of_next_month(date) and > MyApp.AprilBased.beginning_of_next_month(date) and they would return > different results. The benefit is that you keep the data representation the > same and choose how you want to manipulate it. > > Do you have any preferences? > > >> I think the idea of representing a date as a {y, m, d} is effectively an >> encoding mechanism that happens to be the same as the proleptic Gregorian >> calendar - a case which matches the calendar in use by a lot of people >> thereby making it convenient and easy and I’m not proposing any alternative >> to that. >> > > Yes, we have discussed both y/m/d and second based and the consensus was > around {y, m, d} due to conversion cost and pattern matching benefits. > > Thanks for the e-mails! > > -- > 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/CAGnRm4JzQOf2F-sO%2BZy4dYo% > 2Bn-UqOph7eer5dpLqD9TxJ8brPA%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JzQOf2F-sO%2BZy4dYo%2Bn-UqOph7eer5dpLqD9TxJ8brPA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Wojtek Mach -- 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/CADmQCnpnq%2B7q56Dc8FSxsk-bgHWYa3P283n502RLfq91-SswdQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
